Undo oddity

[Dave Labrecque]

This is weird...

I've been working on this session for a couple hours. I've been using undo occasionally as normal, but this last time I did something by accident that made all my FX on track 1 disappear. I think I hit a few keys by mistake that caused channel 1 to clear via the mixer alt-right-click context menu. In fact when I do that again on purpose I can recreate this oddity. Here's what happens... after clearing the current channel (which clears any patched FX, of course), if I do an undo, the FX don't come back.

However, I can open up the undo history, watch it step back through the undo levels as I use the undo/redo key combos (with FX continuing to be missing), but when I double-click on one of the recent levels to select it (instead of using the key combos), all the FX come back.

How can this be? Shouldn't the FX come back using the keys? Isn't selecting an undo from the history supposed to be the same as using the keys? :confused:

[UpTilDawn]

Boy, I would have thought so, but this may answer some oddities I "thought" I'd experienced in the past.... Don't ask what... I just worked things out and moved on....

DanT

[Dave Labrecque]

Boy, I would have thought so, but this may answer some oddities I "thought" I'd experienced in the past.... Don't ask what... I just worked things out and moved on....

DanT

I've noticed some undo issues in the past, too, like where you can only get to an undo level from one direction (e.g., by redoing, but not by undoing). Know what I mean?

We'll see...

[Bob L]

It seems like if it is in the Undo History List, then it should come back from there or from the keyboard shortcuts...

I am guessing that it does... but what I am thinking may be happening in this example is that the Clear Current Channel from the mixer views is not creating an undo... so you are not stepping back to an undo level where the FX were patched in...

You can see this by having the Undo History window open when you exercise that Clear Channel command... no undo entry is added.

I will look into that... but I believe that is what is going on... and... remember that none of the basic mixer changes create undo files... you would have to use the manual snapshot command...

And remember some of the reasoning behind not creating undo files for basic mixer changes... for instance if you grab a fader and drop it 10db, you would have just written 40 undo files... one for each actual data change required in that move... it gets pretty nasty and difficult to keep control of.

Bob L

[Dave Labrecque]

It seems like if it is in the Undo History List, then it should come back from there or from the keyboard shortcuts...

I am guessing that it does... but what I am thinking may be happening in this example is that the Clear Current Channel from the mixer views is not creating an undo... so you are not stepping back to an undo level where the FX were patched in...

You can see this by having the Undo History window open when you exercise that Clear Channel command... no undo entry is added.

Bob,

I'm afraid what's happening is that using the undo key combos is giving different results than double clicking on the undo history entries, even though the undo keys are taking me right through the same history entries! :eek: I can step back through the same undos -- as displayed in the history list -- and get different results. With the keys, the FX do not come back. With the manual selection from the list (double-click), the FX do come back. Weird, huh?

Try this:

1 Add some FX to the pre patch point on channel 1.
2 Add some audio and do a few editing operations on track 1.
3 Select 'clear current channel' from the channel 1 context menu -- the FX go away.
4 Undo. Undo again. Undo again. The FX are gone and won't return.
5 Open the Undo history and double-click on any of those last few undo levels -- the FX come back. :confused:


And remember some of the reasoning behind not creating undo files for basic mixer changes... for instance if you grab a fader and drop it 10db, you would have just written 40 undo files... one for each actual data change required in that move... it gets pretty nasty and difficult to keep control of.

I remember that. (not related to this problem, I think, but...) The one thing I still don't understand is -- why does a fader move have to create 40 undo files? Why can't it create just the one as defined by the place where the fader ended up after you released the mouse button? I don't think any of us do 40 .25 dB clicks in a row. Maybe a few clicks. But the big moves are dragged over several dB, right? What am I missing, here?

[Bob L]

Dave,

You are forgetting there are other ways to grab a fader... like a control surface... how do I know where you ended up... that requires special touch sensitive faders which only a few controllers have and which require special programming to interact with... there are other issues also...

So... to be fair... if an undo is created for any control or switch change... it has to trigger each time a data value is stepped... as you grab a fader and move it, you are stepping through every .25db change... otherwise, you would not hear the results as a smooth fade and only hear a sudden volume jump when you let go... there is a lot going on to make this all happen... you have to look a little deeper than just the surface.

As to your undo test.... the keys do the same as the undo list... BUT... you are still skipping the fact that the undo list does not add an entry after your clear channel... so the FX as patched before the clearing have not been properly saved in an undo... therefore it all depends on when the FX were patched what will happen as you step back and forth... they will appear only when an undo is recalled that was saved after they were patched.

Bob L

[Dave Labrecque]

Dave,

You are forgetting there are other ways to grab a fader... like a control surface... how do I know where you ended up... that requires special touch sensitive faders which only a few controllers have and which require special programming to interact with... there are other issues also...

Actually, I did think of the external controller scenario, but I'd hoped you wouldn't. ;) Seriously, I figured the undo code could easily detect if the input was mouse- or midi-controller-based, and so my question would still hold up for mouse control. No?


So... to be fair... if an undo is created for any control or switch change... it has to trigger each time a data value is stepped... as you grab a fader and move it, you are stepping through every .25db change... otherwise, you would not hear the results as a smooth fade and only hear a sudden volume jump when you let go... there is a lot going on to make this all happen... you have to look a little deeper than just the surface. I'm sorry for not looking deeper than just the surface, but I don't have the fancy underwater-code-goggles that you do. ;)

Again, my admittedly layman-esque, yet still inquiring, mind asks, "I can see the program following all those incremental changes for the playback engine to produce the smooth, hardware-like monitoring experience, but why does the undo function have to acknowledge all those intermediate dB steps in the case of mouse control of a fader? Can't the undo code think for itself and just grab the last value, ignoring all those others that served their purpose well (for monitoring purposes), but are no longer needed?"

You say there are other issues also. Damn those goggles, again. Oh, well, I'm sure there are many things "under the hood" (mixing metaphors, now) that I will never understand. That's why we pay you the big bucks. When you let us, that is. :)


As to your undo test.... the keys do the same as the undo list... BUT... you are still skipping the fact that the undo list does not add an entry after your clear channel... so the FX as patched before the clearing have not been properly saved in an undo...I thought they were saved with every undo. :confused: I thought we could change the extension of any undo file to EDL and it would open right up as a regular session. Are you saying we'd only get a partial session?


therefore it all depends on when the FX were patched what will happen as you step back and forth... they will appear only when an undo is recalled that was saved after they were patched.The last several undos were saved after the FX were patched. That's the whole reason I expect them to bring the FX back when they're stepped back through. Sorry, I don't follow you here.

I'm trying to get my head around this, I swear. Are you saying that when an undo level is saved, the FX are not saved with it? Cuz when the patch points have FX in 'em, and I split a region in the MT, an undo is being created and I've always thought that the whole dang EDL is saving right then. That would include the FX that are patched, would it not?

This still doesn't seem to explain why undo keying to an undo history entry is different than manually selecting it. Double-clicking on it seems to prove that the FX are saved with the undo. At every one of 'em. But that info's not acccessed when undo keying to them.

I know I'm starting to repeat myself, but this is not making sense to me. :(

Even if I'm just not bright enough to understand the machinations under the hood, don't you think it oughta work differently? You know -- like an undo. ;) I mean, shouldn't we expect that an undo will bring us back to the place we were recently (I think that's more or less the "definition" of an undo), like within the last few seconds? In an instant my FX were gone and not coming back... and I'd patched them, like, 20 minute earlier. It also seems a bit unorthodox that manually selecting in the undo history gives different results than stepping back through the identical history with the keys. Don't you think? :(

[Bob L]

Ok,

I was able to duplicate the problem... I'm looking into it.

Bob L

[Bob L]

Ok... it gets complicated... but here goes...

The key operation was altered a while back in order to facillitate rapid undos that are sensitive to various partial parameters based on what areas of the edl were affected at the time of undo creation... this was done because many plugins and video file projects could take quite a while to load when initialized... especially vst synth plugins... which sometimes load their entire sample set when an edl is loaded.

This update increased the normal project flow tremendously by not reloading FX patches or Video files that were not affected at the time of the undo creation... this also helps improve the undo speed when using the Midi Workshop and editing midi notes... there is no reason to reload all patched plugins and video files.

This special routine parsing is creating this side effect when you step back through the undo list in the case of this FX removal that did not create an undo file.

Using the undo history bypasses all parsing and opens the entire edl as if you are loading it from the main file menu...

So... the solution here is for the Clear Channel commands to become part of the undo file creation loop... I'll set that for 4.0.

Bob L

[Dave Labrecque]

Ok... it gets complicated... but here goes...

The key operation was altered a while back in order to facillitate rapid undos that are sensitive to various partial parameters based on what areas of the edl were affected at the time of undo creation... this was done because many plugins and video file projects could take quite a while to load when initialized... especially vst synth plugins... which sometimes load their entire sample set when an edl is loaded.

This update increased the normal project flow tremendously by not reloading FX patches or Video files that were not affected at the time of the undo creation... this also helps improve the undo speed when using the Midi Workshop and editing midi notes... there is no reason to reload all patched plugins and video files.

This special routine parsing is creating this side effect when you step back through the undo list in the case of this FX removal that did not create an undo file.

Using the undo history bypasses all parsing and opens the entire edl as if you are loading it from the main file menu...

So... the solution here is for the Clear Channel commands to become part of the undo file creation loop... I'll set that for 4.0.

Bob L

Now THAT makes sense. :) Agreed that the workflow inprovement via the parsing was a great thing. Good to know that the fix will be as simple as causing the 'clear channel' function to creat an undo file.

Thanks for looking into this, Bob.