What often throws me in Ardour and causes interruption to my work is ‘undo’ when it jumps between zoom levels, particularly when I perform multiple undoes. It can then take me a while to find where I was on the timeline by which point I’ve forgotten why I was reverting in the first place. Otherwise I can’t be sure that it’s undone the change I requested as it’s moved from the place on the screen were my visual focus was.
I see this topic has been been broached before, but this was 2015 - History + Zoom level Is there now a setting to perform undoes without jumping zoom levels? If not how do other users work with this?
It was motivated by users who want to re-do the part that was just undone. So the focus should return to the area of interest just before the action was performed.
This is also particularly helpful if the undo action modifies data somewhere outside the currently visible area. Otherwise you have no direct confirmation of the undo operation.
I think this feature might help in some very specific use cases, but in many others zoom level jumps just makes you lose your position in the session and also lose focus on what you where doing (need to find position in the session again). I think decoupling these features and a selection box would make both camps happy.
Robin literally hit the nail on the head no surprised, especially the second part. If you hit undo and don’t see anything happen, then how do you know what actually happened? That is a huge UI issue honestly to me. I am not saying the behavior can’t be improved, but at the very least you always need some visual feedback for a command. On the flip side, if the action undoes something already visible on screen it is more debate-able whether a zoom level needs to change.
Are you sure you really see what the undo changed ?
I find that after pressing ctrl + z the change has already happened when the screen redraws and you have no idea what changed. You really need to have your eyes nailed to the position where the undo change is going to happen to really see where the change takes place. This is especially true if undo changes something that is outside the visible timeline. Then your eyes just registers that the screen flickers and you have lost your place in the session, there really is no chance to target your eyes onto the position that changes, the change has already happened.
I have used many DAWs and this feature really bugs me every time I use Ardour. It is obvious now that I’m not alone (there are others in this thread ). I wish that people just stopped trying to tell me that I’m wrong, it won’t make the feature work for me.
It’s obvious that there are two camps here and both could be satisfied by giving the user a opportunity to choose. Without any deeper knowledge about Ardour code base I guess that it would be a relatively small change to the code. Undo could perhaps internally work like it does now storing user edits and zoom levels but when the user presses ctrl + z it would restore edit changes with or without zoom level restore.
Yes, but for exactly the reason. When I perform an action I am visually watching for that action to make sure the expected action happens. This is true with any piece of software for me, I have had to many times where I do something and I expect one thing, and find out something else happens. This becomes especially true when teaching the software honestly, students need the visual feedback to understand what they have changed (Or Undone a change) in my experience.
And that is exactly why Zoom level was included in the undo stack. Again I am not saying that the way it is implemented right now is the ‘best’ way, but I do personally believe it is better than risking an action with no feedback at all of what happened.
You have been around enough you should know I am not saying ‘You’ are wrong. Just that I believe that a default of a lack of feedback for an operation is wrong. It doesn’t mean that there aren’t other ways to address it either, for instance in some software you have a textual description pop up as a notification for what happened, or you might have a visual stack of operations that you can see step through as you perform undo/redo. These are just two examples and I am not saying either are a good fit for Ardour, but they are other ways they are addressed in other styles of software to ensure some feedback/confirmation of an action is performed.
And what I am trying to encourage is rather than just simply ‘Add a checkbox and move on’ which tends to encourage bloat in preferences etc. and make it more difficult for people to find what they want in behaviors, to encourage conversation about other ways of addressing the concern that led to the inclusion of the zoom in the undo stack to start with. There is obviously always a time and place for adding options in preferences, again don’t misunderstand me, but I don’t think that should be the first step, and instead should be a step of last resort if no other better answer can be found.
Sorry if I sounded edgy in my last post, that was just the low blood sugar level talking
I’m glad we are discussing this now and I can see some merit in every opposing point made here. The idea of zoom level restore is nice, but there are cases where it makes things harder rather than easier. It might make things better when you only undo one thing and that edit happens to be on the visible timeline. But when you need to undo many changes you did in the last 20 minutes it really makes things harder. Screen jumps all over the timeline and you really don’t have time to see what the undo did and where. Without the zoom level restore feature I could zoom out to see all the session and undo one by one and see regions move and dissapper. If I do not see the change I can redo and undo until I spot the place. Zoom jumping makes this impossible.
For the feature to be really useful the user needs to remember the sequence of edits he did and on what position on the timeline. Then he can focus eyes on those parts and press ctrl + z until he reaches the point that he seeks. But when you can’t remember the exact edit sequence or positions because there are so many of them then the usability falls apart.
And what if you have two monitors and the timeline stretched across it, how can you spot the undo change then when you don’t know on which monitor it is going to happen ?
I wanted to visualize what I experience when undo does not work for me so I opened a session for a song we wrote in January 2019. The session still has 20 last edits in the undo history, so I made a video going through all those levels. See if you can spot what the undo changes and where. I can only see changes when the zoom level does not change.
I want you to watch especially those undos where zoom level jumps. You can see that the change has already happened when the screen redraws and the only thing you really see is the jump in the zoom level. It’s really impossible to see what changed.
If there is something I’m doing wrong with the undo then please tell me, I would very much like the feature to work for me
This is convincing, at least of part of the overall story.
The technical side of the story is more complex. To do this “right” would mean storing complex information in the undo history. The design of the undo system is as “anonymous” as possible - it doesn’t store “known operations” but anything you can do inside the program. This means that an element of the undo history does not contain any accessible information about what it changed or how it changed it. It is simply what us programmers would call a “closure” - when invoked it will undo (or redo) some changes, but we can’t analyse the undo/redo element and find out what those changes will be.
The ideal solution to this problem to me seems to be a compromise that simply ensures that “the objects changed by the undo/redo have the same on-screen visibility that they did when the action was originally taken”. That would mean that moving a region, for example, then scrolling a half-screen in a way that leaves the original position of the screen visible, and then undoing … this would not scroll back to where you were before but would leave the screen as-is.
Right now, I don’t see any way to implement this. It is completely at odds with the design of the undo/redo system, which can store arbitrary transformations.
At the moment, I would lean towards an option. But it will certainly have to wait till post-6.0
As a work around to the closure design would it be possible to intercept the undo / redo just after it has been actioned to check if it belongs to the zoom class(?) and if so action or not action accordingly based on a flag setting? Perhaps this would be the same amount of work as you describe, I’m not a programmer.
Otherwise how do others manage with this? My workaround is to try & never action more than one undo and instead spend the time reconstructing what I want to return to. This is equally frustrating but one in which I feel I have more control over as at least I can see and confirm what has happened.
I can’t see myself ever using zoom level restore and I would very much prefer a global option to just completely disable it. Imho a modifier is needed if you sometimes want to use the feature and sometimes not and I can not see a use case where one would want to do this. Of course this not for me to decide but just wanted to chime in here
I think a modifier is probably the way to go as long as it and regular undo can have their keyboard shortcut edited. Then for those who never want to use the zoom level version, like me and you, we can just assign CTRL+Z to the non-zooming undo method.
). I wish that people just stopped trying to tell me that I’m wrong, it won’t make the feature work for me.