This bug has been around for many versions of Cubase. Automation points at 90 degrees to others will jump to the level of adjacent ones when you move multiple automation points with the selection/hand tool. It only happens when surrounding automation points are 90 degrees, (and happens about 95% of the time)–any less of an angle and it works as it should. Attached is a video to clearly demonstrate (#2 in the video shows the actual bug).
Case: I want to raise or lower two automation nodes both without splitting them off from the others or affecting surrounding nodes that are at 90 degrees.
Re-creation, in order of the three parts in the video:
1: I’m using trim to adjust the two automation points and you can see that this causes a separation in the left side, which I often don’t want. But you can see it leaves the 90-degree node on the right intact, as it should.
2: In order to avoid the separation of using the Trim tool, here I instead use the selection/hand tool to move the two nodes up and down, but you can see that it makes the 90 degree node on the right jump to the value, which it shouldn’t.
3: If I increase the angle of the node on the right you can see that it works exactly as it always should. It’s only when there’s a 90 degree angle (section two in the video) that the bug is present.
This bug causes much frustrating extra time to re-draw automation. The workaround is to move the values in the info line, but this is not modern/intuitive, and we need to be able to do this directly where we’re working. Thanks for listening and fixing!
Gonna keep bumping until I get acknowledgement from Steinberg. This gets in the way so many times every day and feels like it might be a simple fix. Three other composers I know in L.A. (incl. a very famous one!) who are Cubase-ers have also complained about it.
I had a look again. And it works as designed and specified.
If you use the Scale Vertically hotspot, you can change the nodes just in the up/down direction (vertically). Therefore, the rightmost node in your case, stays in the position.
If you click on the node, you can move it up/down (vertically) or left/right (horizontally). It’s totally up to you. If you cross another already existing node with your horizontal move, this node becomes overwritten.
If you want to click on the node and then constrain direction (to move only vertically or horizontally), make the vertical/horizontal movement and hold down the Ctrl/Cmd modifier to enable the Constrain Direction feature.
Thanks for checking it out Martin. The problem is that the Constrain Direction feature doesn’t work properly when moving two or more nodes vertically at the same time as far as this particular issue is concerned, and the adjacent nodes at 90 degrees jump most of the time as if they were being crossed to become overwritten (which they shouldn’t be because of Constrain Direction being held while moving vertically).
90 degree nodes don’t jump? That’s really weird, it’s been happening for many years on multiple systems here (both Mac and Windows), about 9o% of the time, and others have told me it happens to them, too. Here’s another video showing me using Constrain Direction modifer on two selected nodes and what happens. Constrain Direction should make it so the surrounding nodes don’t jump, if I’m understanding what you’re saying. If there’s something else I need to try, do tell!
The exact same thing happens to me as well when using Constrain Direction (holding down Ctrl) and moving nodes vertically as in @Electriks video above.
The second node from the left shouldn’t disappear when moving the two selected nodes up/down.
Yes, as I wrote, that’s exactly what I do/did. Also see mlib’s response. It doesn’t happen 100% of the time, and I can’t figure out why that is, again it’s about 90% of the time. Would like others here to check on their systems to confirm.
Am curious - can you post a screen recording/video of what you see your side please.?
Remember:-
Two or more nodes selected
One of the nodes must be at 90 degrees to another (unselected) node
Hold modifier key for Constrain Direction feature (vertical)
Observe the most recent video @Electriks posted carefully
Try it more than two times
Examine @mlib post confirming the exact behaviour as described by @Electriks
I say all this, because there could be something very ‘special’ or ‘particular’ about your system Martin, and what you’re trying, that others may learn from…
(not at my machine so can’t test myself at C14.0.30 - but I know I’ve seen something of it previously - a while ago - when editing automation)
Thank you so much for checking and reporting, looking forward to a fix ( hopefully it’s an easy one). I do use that workaround, but fixing will save a lot of time/mousing around. Thanks again.
They really need to go through the automation system in Cubase and Nuendo thoroughly and fix more than one problem. It shouldn’t have to be the case in 2025, but really they need to.