Watch the attach vid capture for a very clear explanation. Watch how the leftmost node next to what’s selected jumps when moving the selected nodes. This bug happens when you’re holding the command key in order to move automation sections without going into trim mode, and also to keep it aligned vertically.
Martin, PLEASE tell me that this is an official bug that will be fixed, because it is a workflow killer in a significant way when you edit automation as much as I need to in my daily work. You wrote in the previous thread title about this that it was an “[ISSUE]” or something like that, but there was no case number or anything when I asked, and clearly it didn’t get fixed. Thank you for letting me know.
The problem is, you move the node to the left side a bit. So the node moves to the time before the 1st node, so the 1st node disappear. To make sure you don’t change the time you can:
Use the Info Line and change the value here (by using mouse scroll-wheel, or click and move, or type the new value).
Or You can hold down Ctrl/Cmd while move ing the mouse down, to constrain direction.
Sorry Martin, it’s a bug since 9.5. The video is using Ctrl/Cmd, because if it wasn’t then it would trim the automation with the newer trim feature instead of just moving it up and down. The node doesn’t move to the left at all in the video. This issue needs to be fixed.
Can others here confirm this bug? It happens when you use Ctrl/Cmd mod key when moving multiple automation nodes up and down, when one of the adjacent nodes is at an angle. I’ve recreated the bug on two other Cubase setups of friends, one on Windows and one on Mac.
There was feature change in Cubase 9.5 in this area. In Cubase 9 you cannot move a node ahead of or behind another automation node. So if you reach a position of other automation node, you cannot move it further. This has been changed by design in Cubase 9.5. Since then you can move the automation node freely, you are not locked in the boundaries of previous and following automation node positions. As a side-effect, the thing you described could happens. As a solution, use this Constrain Direction function (hold down Ctrl/Cmd). The function is there in Cubase for these use cases. If you want to change the value, but not the time.
It’s not a bug, therefore you can reproduce it at any Cubase installation.
Like I told you specifically before: I am very specifically using Ctrl/Cmd when I experience this issue. Please be aware of this when responding. This is different from what you are saying, and only serves to destroy automation work. You should be able to move automation while using Ctrl/Cmd and not affect surrounding nodes that are directly above or below the ends of what you’re selecting and moving, but aren’t selected. You can see precisely in the video what I’m taking about. This should not and does not need to happen with the new design because, again, it only serves to destroy some adjacent parts of your automation.
This bug is making me crazy and causes a lot of wasted time over the course of any project. It only happens when you hold down the CMD key in order to keep Constrain Direction and/or to line up the automation with a previous point by using the alignment line. See the first post for a vid of what the issue is. This very much needs to be fixed and is another thing to add to the list of workflow issues that get in the way. This happens on every Mac I’ve tried Cubase on (including at NAMM and at Guitar Center).
i can confirm this bug, even though it happens randomly here. (maybe it was also fixed in 10.0.15?)
also, when 2 nodes are set to “-oo” they can’t be moved via the click+drag anymore at all, whereas changing the value via mouse click+drag in the inspector works fine.
also, when marking a range at, say, 0db, and lowering the value to, say, -3db, via click&drag, after selecting the upper “left-over” 0db nodes again, those can’t be moved at all via click+drag, whereas (same as above) in the inspector values can still be changed via click+drag.
these are definitely bugs. can anyone at SB please please confirm this and apply a CAN number?
Thanks for confirming, and the bug you reported is a valid one too. I’ve tested the bug I reported on multiple systems and it happens on every one of them. Unfortunately it hasn’t been fixed in 10.0.15.
This is different from what you are saying, and only serves to destroy automation work. You should be able to move automation while using Ctrl/Cmd and not affect surrounding nodes that are directly above or below the ends of what you’re selecting and moving, but aren’t selected. You can see precisely in the video what I’m taking about. This should not and does not need to happen with the new design because, again, it only serves to destroy some adjacent parts of your automation.