Inserting Tempo Changes has suddenly started altering earlier clips. Help?

I am doing some very finicky time correction work using Slip Stretch on 9 audio tracks (grouped clips) and running into all sorts of time consuming quirks in Sonar.
 
This one however is totally stumping me and I need to figure out what's up.
 
I've been splitting and Slip Stretching the grouped clips to a steady timeline however there are certain spots where I need to let the tempo "breathe" a little (or a lot) to hang on to some of the human nuances in the material. When I hit a spot that need to be sped up/slowed down and I know the exact tempo I want I am setting the Now Time and using the Tempo View to insert the new Tempo at that location.
 
*side note... At first I had been using the "Project > Insert Tempo Change" method of doing this and I thought that was working but then I started noticing that it was applying the change to sections BEFORE where the Now Time was set at thus screwing things up before the desired Tempo Change. It also seemed to be choosing an arbitrary range to apply the Tempo Change to (like it would keep the original tempos or other changes and just apply the new tempo somewhere totally weird and unwanted).
 
So I switched to inserting the changes using the Tempo View (setting the Now Time, pressing the + button to insert the new tempo). That seemed to be working fine for quite a few of these little changes.
 
NOW though, for no apparent reason, if I insert a tempo change using the same method the clip preceding the Tempo Change goes out of whack. Essentially the end of the preceding clip lands right on the Measure line and the start of it lands at my last edit (which is slightly before the measure an earlier measure line to accomodate an X-Fade on the previous clip). These clips are "slip stretched" BTW... just so that's clear.
 
What happens is the end on the clip in question nudges backward (away from the measure line) and the start of it jumps forward thus ruining my X-Fade from the preceding edit and/or totally pulling away from the previous clip.
 
The Tempo is NOT changing at ALL for the duration of the clip (which is confirmed both by the Tempo bubble in the Transport Module and in the Tempo View). The Tempo is only being changed for the section immediately AFTER the clip so the relative time between the clip and the timeline should not be changing at all (which is normally what would cause a clip to do weird stuff like this).
 
As I said this is all audio (not MIDI). Each track only has one clip each and this WAS working up until now (unless somehow I've inadvertantly changed my procedure which is possible but I don't think so).
 
I've done some tests to see if I can pinpoint the problem like using "Set Measure/Beat at Now Time" before making the tempo change. I tried inserting the change further down the Timeline to get it well away from the clip.
 
No matter what I do that group of clips (for that time range) STILL shortens/shifts/goes of the timeline.
 
It's kind of crazy.
 
 
I really hope someone can shed some light on this because it's a major problem. Is this a bug? Is my project corrupting?
 
Any ideas would be great. I know this is "advanced" editing stuff but hopefully someone here knows the type of work I'm talking about.
 
Thanks.

I always find it a little tough to understand exactly what's going on from a long written description, but is it possible that the slip-edited-away portion of the clip is for some reason being affected by the tempo change? In other words, if you bounce-to-clip the slip edited clip to fix the edit, does that change anything?

I understand. I just thought that maybe if you bounced a clip that had a slip edited ending BEFORE the tempo change but a "true" ending AFTER the tempo change, perhaps it might make a difference (so the "true" clip ending would also before the tempo change).

Okay... I'm gonna toss out a thought/idea I had that may or may not benefit this situation but I don't fully understand it so hope some of the smarter dudes can chime in.
 
I know there is a setting somewhere for "relative time" or something like that that allows the tempo to be changed while clips or events stay in place. I don't fully understand it and have only come across it a few times so forgive me for being vague.
 
Essentially it's supposed to be for film scoring and similar tasks where you can manipulate the timelime without clips going all wonky.
 
I doubt that's the solution I'm looking for but maybe it is. If anyone knows what I'm talking about some insight as to whether it might be a way to manipulate this situation to my advantage I'd definitely want to understand/try it.
 
Cheers.

rlared
Hmmmm what if you insert the tempo change at one tick after the measure?  So instead of 3:01:000 you insert it at 3:01:001?  My theory is that the tempo change insert is overlapping with the clip which is screwing up the stretch and making it reset or something?

Yeah, it's a great thought but I actually already tested that earlier today. I thought maybe because I was stretching the ends of the clips to a tick or two after the measures the tempo change was sucking the clip into it but even if I set the tempo change way down the timeline it still screws up the previous clip.
 
Nice catch though. I guess if anything this is documenting this oddball issue for anyone else running into it.
 
Cheers.

As a follow-up, I'd check everything in the Clip Inspector actually.  I've had tons of headaches when the "Beats in Clip" was not correct, it would act totally weird when changing tempo.  Maybe an AudioSnap setting is wrong as well.  Not sure if stretching a clip engages AudioSnap for that clip or not.

@rlared
 
Hmm... interesting thoughts about checking the Clip Inspector.
 
Thing is I'm not using Audiosnap for this (yet). The clips are not "Groove Clips" either.
 
I'm just the Slip Stretching the audio to pull in (or out) sections that are lagging (or speeding up) too much.
 
For example... if the downbeat at Measure 10 is on Beat 1 but the section lags over time so that the downbeat that SHOULD be at Measure 20/Beat 1 actually appears at Measure 20/Beat 3 (or somehwere close to it) I create the split at the downbeat and slip stretch the clip back so the downbeat actually lands at Measure 20/Beat 1.
 
Well the downbeat would actually appear in the NEXT clip right after the split so I'm pulling back the spot just before the downbeat. Then I snap the downbeat clip to the measure and create the X-Fade (by slip editing WIThOUT stretching the start of the following clip across the end of the preceding stretched clip ever so slightly).
 
In theory audiosnap or clip tempos shouldn't have anything to do with it. Just the clip(s) getting compressed or expanded and only the split point getting snapped to the timeline (not the transients).
 
That's keeping the human performance. Once I get the overall songs tightened up and the stretched clips bounced I'll use Audiosnap "Merge and Lock" wackiness to make any finite adjustments needed.
 
So maybe Audiosnap IS in play here or something but it still doesn't make much sense why a tempo change completely separate from clips further down the timeline would make clips change size when the Tempo displays are showing no tempo changes have occurred where those clips exist.
 
It's very strange... and that post/description probably sounds strange too. lol
 
Sorry, just typing what's going on.

brundlefly
I don't think it's really feasible to troubleshoot this without seeing the issue firsthand. But in general, I've never seen a tempo change affect anything earlier in the project, so I would guess either you're encountering a bug that's peculiar to this project, or you're inadvertently changing the previous tempo rather than inserting a new one (there's and option for this in the dialog). Since, the M:B:T timeline is the fixed visual reference in SONAR, if you see an audio clip changing length or start time, that's generally prima facie evidence that at tempo change has been made somewhere before the end of the clip. 
 
From what you've described, I think my approach would have been to align the timeline to the existing audio using Set Measure/Beat At Now, and then enable autostretch on all the clips, and massage the tempos in the tempo view to achieve the desired result.
 
Attempting to combine many different approaches as it seems you are doing is bound to get "weird" at some point, especially with many tracks having separate clips and un-bounced crossfades. Setting the Timebase (i.e. start time reference) to Absolute might address the problem, but it's hard to say without seeing exactly what's going on. And, again, it shouldn't matter if the tempo change is being made after the end of the clip.

Hiya, Brundle. Thanks for popping in. Based on your post I think this really could just be project corruption due to so many unbounced stretches. I was really trying to avoid breaking up my bounces and just do a full bounce of everything at the end (the songs aren't long and I'm trying to keep the splits/stretching to a minumum). However I guess I'll try pushing through a third of the tunes at a time (or something like that) with the stretching moves, bounce the work then move on. Not sure exactly how this will look but I guess I can muddle my way into having three or four sections (grouped across the tracks) then flatten or bounce them together once it's done.
 
MAYBE that will keep the project chugging along. And yeah... as I've been wrangling with all this I've been contemplating making a video to show a bunch of the annoying stuff that I'm encountering... however this particular issue definitely seems like an intermittent/project specific thing. At least I hope it is because I'm only on song 2 of this session and I'm starting with the simplest stuff. This simply cannot happen for the longer/weirder songs.
 
As far as the method of setting the tempo/timeline beforehand that's how I originally tried this ages ago (X2 days) then snapping/adjusting around that... unfortunately the music is far too chaotic for such shenanigans. That's why I'm having to "earball" it and micromanage each section.
 
The tunes are 180-200+ bpm and all "punky/metal" with lots of fills and stuff so the prep work to make autostretching happen accurately would take WAY longer than doing it manually the way I am. So I'm just trying to get an overall tempo and smooshing the natural performances into it section by section.
 
The end result is sounding great. It's just getting there that's causing me issues.
 
If tempo changes should NOT be affecting clips earlier in the timeline though I am definitely experiencing bugginess so that confirmation is helpful. It was definitely working the way I want before so hopefully with a little more of a gently touch and bouncing more regularly I can get on with this project.
 
I've got nine of these songs to do and I'm only on track two (and may have to redo track one). Also we recorded two versions of each song so I want to correct BOTH versions to the same timeline in the same project so I can raid drum fills and vocal parts where needed (I am retracking all the guits and probably bass). I haven't even touched the second versions yet. lol
 
Brute force, yo.
 
Thanks again, Brundle.

rlared
I agree it's very strange.  For the purpose of keeping things clear, let's call the clips "Pre" and "Post".  Pre is the one that shouldn't be changing but it is. 
 
In the above example, you're splitting the clip at measure 20 bar 3.  Then I believe you're then slip stretching "Pre" so that it ends at bar 19 and then changing the tempo at bar 20.  The only thing I can think of is that perhaps slip stretching is just a "modifier" in Sonar.  So essentially it doesn't edit the clip but just tells Sonar to play it faster or slower.  In this case, Sonar still may think the clip extends into bar 20. 
 
Did you try bouncing it to a new clip after stretching?  That may help.

Once I move on to the next song (or maybe the second version of this current song which I will be aligning to the version I'm working on so I can raid for comps) I think I'll try bouncing the stretched clips in sections instead of trying to wait until the end of the song and bouncing all at once.
 
Yes, I do believe that until bounced Sonar is just reading back the stretched files differently so it could be I've overloaded the project with data leading to project corruption.
 
I've also occasionally been getting this MIND TWISTING noise when starting playback like a million sparkle demons invading my ears all at once. It's not loud or anything but it's such a strange and jarring noise that it makes me almost launch my headphones across the room.
 
That to me is indicating some kind of Disk reading problem. I use HDD's (not SSD's) and that has always seem to be the most problematic part of my system so a problem reading back and translating the data could be what's corrupting the project.
 
Just guessing and I'm not smart enough to fully diagnose it.
 
Cheers and thanks.

Sure.buses can also be set. You can select all clips at once and update them collectively. Tracks must be altered one at a time.

Beepster

rlared
I agree it's very strange.  For the purpose of keeping things clear, let's call the clips "Pre" and "Post".  Pre is the one that shouldn't be changing but it is. 
 
In the above example, you're splitting the clip at measure 20 bar 3.  Then I believe you're then slip stretching "Pre" so that it ends at bar 19 and then changing the tempo at bar 20.  The only thing I can think of is that perhaps slip stretching is just a "modifier" in Sonar.  So essentially it doesn't edit the clip but just tells Sonar to play it faster or slower.  In this case, Sonar still may think the clip extends into bar 20. 
 
Did you try bouncing it to a new clip after stretching?  That may help.

Once I move on to the next song (or maybe the second version of this current song which I will be aligning to the version I'm working on so I can raid for comps) I think I'll try bouncing the stretched clips in sections instead of trying to wait until the end of the song and bouncing all at once.
 
Yes, I do believe that until bounced Sonar is just reading back the stretched files differently so it could be I've overloaded the project with data leading to project corruption.
 
I've also occasionally been getting this MIND TWISTING noise when starting playback like a million sparkle demons invading my ears all at once. It's not loud or anything but it's such a strange and jarring noise that it makes me almost launch my headphones across the room.
 
That to me is indicating some kind of Disk reading problem. I use HDD's (not SSD's) and that has always seem to be the most problematic part of my system so a problem reading back and translating the data could be what's corrupting the project.
 
Just guessing and I'm not smart enough to fully diagnose it.
 
Cheers and thanks.

It probably is Sparkle Demons. They fly into your ear and steal your sanity bit by bit.

If it does it repeatedly in future projects, submit a bug report though

Buses need absolute for envelope automation on the buses.

gswitz
Buses need absolute for envelope automation on the buses.

Ah... yeah that makes sense. Thanks. That was making my noodle itchy... and yes I may need to do some bus automation eventually.
 
However I may just import the files into a blank project. Not sure if I can import tempo maps though. Maybe via template. Bapu explained it to me a while back but I dun fergot.