usually when having automation on a track and you add some points somewhere on the lane, you can undo those points again. Its also possible to undo changes by using the mixconsole history.
However there is no way to undo a change when you add the first point to an automation lane.
You can undo the point, but the change remains. Like this you can accidentally add points and alter i.e. volumes in your project without being able to go back.
If that happenes to me, the only thing I can do is opening the last backup file, check what the volume setting was and revert it back to the original value in the actual project.
This is the case for all kind of automations of course, not only volume.
Check out the video I made:
The original volume was set at -12.8 dB
I drew an automation point to -14.4 dB
in the edit history you can only remove the point, but the volume change remains, so it stays at -14.4 dB
Steps to reproduce:
Create a track
open its volume/pan/etc. automation lane
be sure there it is the first automation point
draw a point and move it down or up to change the automation value
Sorry Steve, most of the times I am already OK with it, when reports about multiple inconsistencies in a program get classified as a feature request in this forum, even if I think they should be seen as an issue, because they seem more accidental than by design most of the times.
But in this case I have to offer resistance, as this isn’t even an inconsitency, but a bug. This can in no way be “as-designed”.
You can undo basically everything in every situation, but this one. Volume changes usually show up in the MixConsole history and changes to automation lanes show up in the edit history. This here does not show up anywhere.
There is no way you can see this as intended behaviour, they most probably forgot to include this scenario in one of both edit histories.
To me the logic is that the action to be undone is explicit: adding an automation point.
I’m not saying I think it’s good (or bad). Though maybe a programming choice had to be made at some point over the past two decades for other under-the -hood considerations. (I’ll stipulate that it would be more convenient. )
I don’t think it makes much difference whether it’s classified as an FR or bug.
Anywho, the devs use a database for listing bugs, FRs, and other requests from customers, and the developers themselves. It’s all in one place, all perfectly visible to the project managers.
In the event that one of them browses the forum, it’s a good idea to use the feature request tag.
I think it does, because bugs can be reported as a support ticket and a member of the team will get back at you directly after some time with a possible solution or a statement, that they put it in their to-fix list or are at least considering it.
But a feature request this small, will be lost in the vastness of this forum and people will be finding it after 10 years and still ask, how it is possible, this has never been looked at (happened already countless times). Their explanation would probably be, that it did not have enough votes.
It appears to me that the logic behind an Undo function in the world of computing is to get the user back to the state the program was in before a particular command was invoked. There may be some exceptions, but in my experience, this is how Undo works in any/all software.
If I use the command in Cubase Remove Selected Tracks and undo it, I expect the tracks and its parts/events to come back, not just the tracks themselves.
I firmly believe this is a bug regardless whether or not it is a design compromise or oversight.
I will second the notion that this is a bug. Undoing something means not just undoing the thing, but also the impacts of that thing, in this case, as @mlib correctly observed, undoing the automation point add should get you back exactly into the state you were in before you took that action. Otherwise, what’s the point of the undo if it doesn’t … fully undo?
I’m glad this was raised as it would explain a few incidents in the past where I had mysterious volume changes that I couldn’t explain (I use automation heavily, and often undo automation if experiments don’t work out) - and this would explain it
Anyway, it’s just semantics. And any TL3 forum member can add an FR tag to a topic.
It’s not we forum participants who decide something is a “bug”, it’s the dev team – and the definition of that word is pretty ambiguous. The term issue is more apt.
Thats why I added the “issue” tag to this thread. Because if I use the undo operation to basically undo what I just did, and it is only undoing a part of it, this is a serious issue, as I have no chance to get back to where I was.
And a “bug” is by definition an “unexpected defect, fault, flaw, or imperfection”, which couldn’t be more accurate for this behaviour.
I confirm the “issue”. Well, I can’t really say that.
When we delete all the points, delete the automation track, or like you say, “undo the creation of the first point”, the current value remains.
The Initial Value (that’s the flat line when the automation track is empty) keeps the value that is shown in the value field, and that’s not really a bug (some people clearly don’t like this word apparently) but more of some lack of ergonomics.
I understand what you mean by describing this as an issue. The reason why it does that, is because the “last known value before adding automation points” isn’t saved internally, so when all points are deleted, the Initial Value retains the last current value.
To my eyes this is just a technical limitation. Actually, having the “last value before writing automation” being remembered and recalled when clearing or deleting an automation track is totally possible, it simply haven’t been implemented.
Let’s take a different approach.
Your level fader was at 0 before writing automation, and this “issue” happens. You would expect that the fader will return to 0, since that was its previous value. But it doesn’t work like that, when the automation is read, it moves the corresponding parameter, but taking the volume as example, volume faders changes aren’t stored in the history, even when you move them manually without using automation, that’s why deleting automation doesn’t restore anything, because the parameter simply keeps its current value.
Volume change history only works in the MixConsole, but again, it’s completely independent to the Project Window, and only applies to manual changes, not automation.
Well we can talk about technical limitations,bugs, issues, features, how much we want, in the end this is an “issue” for the user if he wants to get back to where he was. Do we agree?
It doesn’t help anybody, if you know this is not a bug from a dev point of view, but a technical limitation. The “issue” for the end user remains.
If you ask me, there should be created at least a mixconsole change in the mixconsole history when altering the volume by dragging an automation point. But to make it more intuitive and easier, adding this action to the esit history would make more sense imho.
Hello, I finally found a place to discuss this topic. The volume change must be undone. It happened to me several times in big projects (by mistake, of course), and it was challenging to fix it again. There is no way to remember how the original volume value was. I asked Greg on YouTube about the question, and he said there was no solution. This is puzzling because if you insert the first point and then insert a second point and drag it down, it will undo the second point’s creation and the volume change. I think that it should happen a lot to people like me who scroll-press on the mouse to navigate across the project.
The lane point insertion issue, which we previously reported, still persists. Despite my efforts to adapt, I find myself struggling with this problem intermittently. Specifically, I often forget to draw a point at the very beginning of the volume lane and inadvertently drag with the first point inserted, leading to difficulties in restoring the original value.
Has anyone found any workarounds or discovered new insights into this issue? Additionally, does anyone know how we can ensure that the developers are aware of this specific concern? It would be helpful to confirm that they have acknowledged this problem.
