What is saved as Undo for tempo changes - it does not work that well?

[LarsF]

I changed tempo on a small project with 4 tracks 8, 2 each track midi clips - using set measure/beat at Now.

But length and position is not restored on all - just some.

I first set undo to as low as 10 but then nothing just about was restored by Undo inserting a tempo change.

Then set to default 128 some more was restored as result of Undo tempo change, but not all.

Increased to 256 and still one clip did not restore to original size and position doing Undo.

 

History just show tempo change - so how does this work?

Only way to restore is to have project saved before doing tempo change, and close and open project again - then all looks as before tempo change.

Undo cannot be trusted, really.

 

Thanks.

Edited February 13, 2020 by LarsF

[David Baay]

Each execution of SM/BAN is single event, and undoing it should completely undo the effects of the resulting tempo change. I use it constantly, and have never encountered a problem with undo - even undoing dozens of 'sets'.

I didn't completely understand the meaning of "4 tracks 8, 2 each track midi clips", but I assume that means some clips are audio. Have you changed the timebase or enabled stretching on any audio clips?

If you could share a copy of the CWP file without audio (the dummy clips Cakewalk will insert should be enough to repro the issue), it would be easier to figure out what went wrong.

Edited February 13, 2020 by David Baay

[LarsF]

Thanks.

I write incomplete -  4 tracks with 2 clips each - only midi.

Same clips actually, duplicated, not linked. 4 positioned at same location, measure 2 or so, above each other to easily see how the Absolute timebase, and lock pos/data worked. And second set of 4 the same a couple of measures further up untouched being musical timebase and no lock.

I experimented with various timebase and locked and unlocked on both the track and the clips - and either way they should just jump back to how it looked in position and length. I was trying out how to eventually tempo match these and how they changed when doing a Set measure/beat at Now.

I could not do one SMBAN in middle of 2st colume of 4 clips and undo and it reverted to same look.

And as mentioned, how much undo is available seems to have something to do with it.

With undo at 10 I thought I would be ok, as I usually felt Undo was the same and amount of rows in history - but seem wider in how it operate. 

Maybe two of 8 clips looked the same in size and position with Undo at 10.

But closing project and opening again they were the same again.

So increased to default 128 and did SMBAN  then Undo- and like 6 of 8 became the same - much better.

 

So I was into doing this experiment and just this behavior of Undo became something I wanted to know more about how it operates.

I will try and provide this little project tomorrow or so.

Edited February 13, 2020 by LarsF

[David Baay]

It's not be necessary to change the timebase of MIDI clips or lock data when using Set Measure/Beat at Now. Cakewalk automatically recalcuates event start times and durations to maintain their absolute playback timing.  Undo functionality might actually get fouled up by changing the timebase. I don't know; I never tried it.

Be aware, incidentally, that locking a MIDI clip does not lock the data to absolute time, it just prevents direct editing. And the timebase setting only affects the clip start time, not event or clip duration.

I would need to understand better what the goal is and see what you're working with to explain more fully.

Whatever problem you're encountering, I don't think it's related to the number of undo levels.

 

 

 

 

[David Baay]

FWIW, I played around with this a bit, and did not get any unexpected results either with executing or undoing SM/BAN with position-locked and/or absolute-timebase MIDI clips.  The results are  different in each case, of course, but make sense if you understand how the the settings work. And Undo always got me back where I started.

 

[LarsF]

Thanks.

It seems two consequtive SMBAN is the culprit, shown in images. Text explain what I did.

I named tracks for 1st column clips Tm=track musical timebase, Ta=absolute track timebase, Cm=clip musical, lock or not, Ca clip absolute lock or no lock

2nd column clips are as first clip musical no lock.

Real problem seem in this test to be musical clip on a absolute track. After two SMBAN both first undo and second does not restore.

I have a bundle project as well that I can post.

[LarsF]

Bundle project of this I did.

Simple project cwb

[David Baay]

Did  quick test, and could not reproduce a problem. Undo twice returned to the original state. Just to be clear when you write 3.0>3.1 and 4.0 to 4.1, you mean set 3:01 to 3:02, and 4:01 to 4:02, right?

I'll keep looking at it, but have to say the premise seems quite unrealistic. I gather you were just experimenting to understand how everything interacts, But the whole point of SM/BAN is to change the relationship between absolute time and M:B:T time wihout affecting the absolute playback timing of any existing material, whether audio or MIDI. The function takes care of that without changing timebase or locking clips, and works predictably in that case.

[David Baay]

Looking at your last screenshot, I can see that the notes in the clip have actually returned to their original positions. The only thing that's not right is that the clip boundary hasn't  reverted to end of the last note after the clip was stretched and re-compressed. I've seen this happen in other situaitons where a clip is lengthend and then shortened. It's a clip-trimming display issue that isn't specifically related to SM/BAN, and it won't affect playback. Sometimes just zooming the view in and out will correct it. If not, you can right-click and Apply Trimming.

[LarsF]

Thanks.

It does not matter exactly what measures you do - but opening dialog it says for beat 1.000 and I increase to 2.000. So numerically there is no difference saying 3.1 or 3.01 unless you mean 3.0.1 in your case. I did all kind of changes changed measure 3 to SMBAN 5, but change in tempo were so big that not so good for this demonstration.

The purpose of undo is to restore to previous state - no matter what. I'll take no excuses for that, unless maybe doing hiddeous big ones like full project wide inserts of time and stuff. 

This happended to be visual stuff that was obvious - using undo in other situations it might just be under the hood stuff - and you may really cause strange things. Something is not right here.

 

The week I worked with Cakewalk now - I had 2 freeze crashes - both as doing undo operations in situations.

One was replace SuperiorDrummer to Addictive drums, did some wrong choice so used undo - freeze as I inserted second time as mono outs instead of stereo.

The other were doing change of undo depth - next project opened without fully closing Cakewalk in between open next project.

I consider Cakewalk really stable, as was Sonar Artist 2015, as was Sonar 4 Studio and Sonar 8.5 Studio.

But Undo, I will avoid that like the plague....doing save before operations frequently to just reopen project.

Edited February 14, 2020 by LarsF

[LarsF]

7 minutes ago, David Baay said:

Looking at your last screenshot, I can see that the notes in the clip have actually returned to their original positions. The only thing that's not right is that the clip boundary hasn't  reverted to end of the last note after the clip was stretched and re-compressed. I've seen this happen in other situaitons where a clip is lengthend and then shortened. It's a clip-trimming display issue that isn't specifically related to SM/BAN, and it won't affect playback. Sometimes just zooming the view in and out will correct it. If not, you can right-click and Apply Trimming.

Thanks for all the help.

I you are happy with length does not restore doing Undo - good for you.

I consider it a bug...it could be corrupt internals of all sort messing things up later on, as I described what freezes I got....changing length of undo buffer, closing project and opening next project with a freeze?????

Edited February 14, 2020 by LarsF

[David Baay]

All I'm saying is there's nothing wrong with Undo specifically related to SM/BAN or reverting tempo changes. If you had told me the clip wasn't getting trimmed back. I could have immediately told you that's a bug - mildly irritating, but it has never caused me any real trouble. 

I missed the part about hangs related to changing Undo buffer size. I haven't ever encountered that because I've seldom had a reason to change it. You should definitely report that.

I;m sure the Bakers are already aware of the trimming issues. Pretty sure I've reported it  myself at least once in the past.

[LarsF]

Ok, many thanks for hanging in there.

It's often like that - different people have different ways of experiencing the same issue.

I'm saying Undo does not restore - you say some trimming thingy.

The job of the Bakers to see what is related to a particular issue or not.