New Bug? Conductor Track Tempo Changes Not Behaving Correctly?

[mhschmieder]

The results of tonight's simple Tempo Change action were so bizarre that I lost confidence that I had even remembered how to do it, so I tried several approaches before reaching clarity on the problem (and that it is a bug), but didn't find it discussed wen I searched on Tempo Change or Conductor Track.

I saved what I originally wrote, after deciding not to post it. I've spent an hour on this so far, and am not sure of the best course of action going forward, but it seems clear to me that there is a recent problem with this feature, perhaps as a side effect of some bug fixes mentioned in the past two Release Notes related to Tempo Change.

The most pertinent behavioral problem is that a Tempo Change pushes forward the Key Change in the Tracks View even though it is at the same place in the Event List. The Markers stay in place, as does the MIDI and any existing Audio (given the workflow I am about to describe).

Initially, I thought Tempo Change was broken 100%, as my rote memory from two decades of doing such edits told me to erase audio just before the Tempo Change in each audio track, then add or edit the Tempo. As that didn't work tonight, I tried skipping the erasure part just to see if a MIDI track would be aligned properly with the beat when triggering a VI.

What finally got the results that I could swear I have gotten for 20 years, was to do a bit of overkill and erase an entire bar except for MIDI events. This worked, except for the Key Changes still moving ahead in the Tracks View in spite of not moving in the Event List.

I suspect that the bug fix mentioned for 11.1 related to Audio Track alignment after a Tempo Change, had a side effect, in that one now has to be precisely uniform in where one trims audio before executing a Tempo Change, rather than just making sure that the Audio Track is trimmed wherever it is convenient to do so in a silent section before the Tempo Change.

Of course, taking this approach means I now have to go over a lot of audio tracks to re-drag deleted audio from note sustains in the previous bar. But generally we end up having to do cross-fades after such actions anyway.

I had a very simple goal tonight, which was to pull forward the Tempo Change of the first verse of a song that has a silent two beats at the end of its Intro, as the gap "feels" too long to me when the Intro's slower tempo is maintained until the downbeat of the first verse. I don't normally have to think hard on such tasks, and do it all the time, so doubt I got rusty.

Anyway, seeing an incorrect screen rendering of Key Change locations is disturbing. Initially I thought the Markers had moved, but they hadn't. For a Time Signature Change, I expect different things to move, and almost feel like I got a hybrid result from a simple pull-forward of a Tempo Change by two beasts. Same behavior if I insert a new Tempo Change.

As I normally don't have to think about this process, seeing unexpected results is very confusing, so maybe something in my write-up is incorrect, but not the repeatable observation about the Key Changes moving in Tracks View as though they are unadjusted Audio Tracks affected by the Tempo Change. They should act just like MIDI and honor their Event Time.

[mhschmieder]

It's crashing every time I try to back out the action from Undo History.

I was hoping to start over, after turning off Snap, which I keep forgetting asserts itself on every project and chunk now.

Maybe with Snap off, the problems won't occur.

I need to back it out anyway, as I haven't yet comped bass guitar or vocal takes on this song, so if I can successfully back out the changes without another crash (and I'm doing them incrementally to be safer), I'll just have to note the intended change and apply it once all track comping is done.