ISSUE: Spurious automation events

I’ve noticed some very strange behavior by Cubase [12] when copying/pasting/moving events that have an automation track with only two states (on/off), for example, bypassing a send, or muting/unmuting something:

Cubase will then create spurious automation events on that automation track that have an “in-between” value (visually), even though the only two possible states are on or off. Here’s a screenshot:


This issue aside, I wish I could just tell Cubase to “decouple” the automation track from its associated audio track since Cubase tends to go nuts with creating all sorts of unnecessary, and often duplicated/on-top-of-each-other events when I edit event placement/length on that audio track.

I’d much rather be able to edit both independently. Is there a way to tell Cubase to change this behavior?


Could you please provide step by step repro of the issue, including the screenshots to see, where the automation nodes are during the process?

There is a preferences Automation follows selection. Disabling this you would decouple the automation and the track the way you expect, I believe.

Disabling “automation follows selection” solves this problem for me, so thanks for that!

With that setting enabled, here are the repro steps to make Cubase create in-between automation events for binary things where … there is no in-between:

  1. Create an empty project
  2. Put an event on the timeline
  3. Automate a parameter that has only two settings (in this example, I’ve added RoomWorks SE as an insert and chose the bypass effect setting for my automation lane)
  4. Add an automation point to enable the bypass before the event
  5. Add another automation point to enable the bypass in the middle of the event

You’ll get this:

Then, (with “automation follows selection” turned OFF), move the event by one bar to the right, and you’ll get this mess. Notice that Cubase has created an automation event that can’t exist (it’s in-between on and off):

I’m not at daw right now, but I believe it works like this :

Since there is no automation point that starts the On state within the Event boundaries, moving the Event will automatically create a new automation point at the start of the Event to replace the “missing” point.
This point will have the same value as where the Event Start was previously crossing.

Toggle type automations only have two states, Off and On, and, assuming that it works in 7 bit like MIDI, Off is 0 → 63 and On is 64 → 127.
We can then observe that it also adds another point just under the first one that has the minimum allowed value for the On state, that is, 64.

In consequence I do not describe this as a “mess” or whatever you would call it, I think it really work as intended.
Since the parameter type is Toggle and has only two possible states, the default values are 0 and 64 respectively, and it is hard coded like this, when you write automation by clicking the bypass button directly, the plugin literally sends these values.

Also, different plugins/parameters may have different ranges for their states but the principle remains the same.


Hi, that all sounds technically correct and is probably how the code works!

But looking at this from a human intent perspective, these two additionally created automation points aren’t just unnecessary, but confusing (especially the one that’s halfway between on and off!).

The intent here was clearly to have the bypass on at the beginning of the piece, and then turn it off halfway through that MIDI part. So when moving that part, why not just move that second automation point by one bar, commensurate with the move of the MIDI part?

This can be worked around by either turning off “automation follows events” (if it’s easy enough to manually recreate that automation intent), or by leaving that on, and just manually erasing the unnecessary/confusing additional automation points that Cubase creates (especially the one that’s exactly in the middle between on and off - I can’t see how that one would possibly be helpful to anybody).

Hopefully this thread will help others who run into this and get similarly confused/annoyed by the need to manually clean up those unnecessary automation points :slight_smile:

1 Like

Let’s say you have a ramp curve and the event starts in between the two points, then it will always create an automation point at the event start with the same “crossing” value. It will then link the two points with a flat line. This is how it works with ramp curves and I hardly see how it could work differently.

I totally understand your point about just “stretching” the curve, but with step curves it works as “states” and not “values”, unlike ramp curves — even though the automation points have a value, but you’ll understand what I mean there :wink:
If you look at the automation track you have the parameter name (here “bypass”) and to the right of it, the “Off” value state.
When you move your event it basically re-reads what state is the start of the event in, and re-writes the state as a new point, which is, in the given example, 64 for Bypass-On.

Basically it’s like turning on the washing machine and selecting a program. If you turn it off and on again, it will reset to the default program.
It works the same with the automation, you put a custom value manually, but the button will actually send its own defined value and override it.

It works like this even with ramp curves, but we don’t notice any value “offset”, as for example, a gain fader at -20dB will always have the same value. There is then no “default” value, there’s only one single possible value for the -20dB “state”, and not 64 like bypass On and Off states, that’s why it won’t jump around.

I’m not sure this is 100% right, as I distinctly recall “in-between” values being created for on/off states that aren’t 64 (i.e. midpoint of a 7 bit scale). If I find a free moment in the coming days, I’ll try to reproduce that behavior.

Either way, the point of all this is that I wish Cubase was smarter about creating automation points when moving/editing events. Right now, it creates a bunch of unnecessary duplicates that I have to manually clean up. More detail on this in the thread referenced below, and I made this particular post to point out those “in-between” on/off automation values that get created but make no sense since there’s only ON and OFF - so at the very least those extra automation points should be fully ON (127) or OFF (0) [if the underlying scale is 7 bit]. My guess is that the code uses the same (linear) interpolation math for automation values that actually use a 0-127 scale, but apply that same math to something that should be binary - hence these weird “in-between” automation points.

I think this is a false assumption. I believe Cubase automation works with normalized 0.0-1.0 values internally, not based on MIDI CC.

I tested this with this example to check @Louis_R’s and @mlindeb observations. While this test doesn’t reveal the resolution of whatever Cubase uses internally to represent automation values (and the specifics of that don’t really matter in this case anyway), it does show that when using binary automation values (i.e. ON/OFF states) that should be represented by 1 bit, Cubase still uses whatever higher-resolution automation values it uses, and as I suspected, most likely uses linear interpolation (rather than inserting some default value) to make these non-sensical neither-on-nor-off values.

To reproduce this screen shot, I simply moved that MIDI part a quarter note to the right, and ended up getting an in-between ON/OFF state that’s about 3/4 in-between:

Hi everyone, I come back to this topic with new content.
I’ll try to add as much relevant information as possible as the issue is quite complex.

Let’s resume :

  1. Automation Follows Events must be enabled in Preferences,
  2. The automation need to be for Toggle parameter (On/Off like Mute, Bypass, etc),
  3. There must not be any node placed between the start of the Event and the value change.
    The first node should then be placed outside or the bug won’t occur.

Expand the parts below to show details and images.
Please read carefully, the issue is very serious, more than what has been discussed already.

Part 1

This first image depicts the initial setup, as indicated by the three points above.
I did the test with the Mute automation but you can reproduce it with any other on/off parameter.
As you can see, the first node is placed half a bar before the Event.

If we move the Event, a gap (different value) is created between the start of the Event and the second automation node.
It doesn’t matter the direction or distance of the Event displacement, here I have just moved it one beat to the right.

Now let’s try with the first node closer to the Event, like this :

The gap is now much smaller.

And now with the node much further :

Here’s the result, the gap is now bigger and the node shows the Off State.
Nevertheless, in the present case, it still behaves as if it was in the On state when reading the automation, so it will still play normally, but it is very important to take note of this, because it means that only the bottom “real Off” position actually acts as Off, I will explain that in Part 3.

Part 2

We saw that the location of the left node interacts with the gap height, but the second node also interacts the same way, except it’s the other way around, the closer it is to the left of the Event, the bigger the gap, and the further it is from it, the smaller the gap.
Of course the location of the two nodes combine and leads to various gap height.




It also occurs when the right node is outside the Event, as the gap keeps getting smaller :


Part 3

And now as a third and most important part, let’s try the same thing with the automation inverted.
The nodes are in the same place, only the On/Off states are inverted :

In this case, the gap is also inverted when moving the Event, and because of that the automation becomes broken, in the meaning that since the real Off state is at the very bottom of the automation lane, and because it now fills the gap instead of creating one, there’s no longer a real Off state, and all the automation will play as On state !!!

And last but not least, when re-placing the Cursor in front of the Event / broken automation during playback, the meters show a brief activity and we can hear a click, and it proves that this “in-between” value isn’t supposed to be there and causes the audio engine to do weird stuff internally.
automation follows events bug

1 Like

That is a wonderful and comprehensive analysis of this, so thank you for that @Louis_R!

And you’re right, it’s actually worse than what I initially observed. Hopefully this detailed report will help the Steinberg engineering team fix this…

1 Like

Thank you very much, and also thank you for observing the issue at first !

I wanted to apologize because I sometimes tend to wander in some of my posts, as we can see in this topic I started talking about “7 bit automation” simply because that was just after posting on a topic about sustain controller :laughing: My bad.

Yes I really hope Steinberg developers see and use these posts. I’ll report some bug when I have some time. Hopefully 12.0.50 will come out this week, we’ll see how many have been fixed :wink:

1 Like