Automation follows(?) events -- Bug or Intended Behavior?

Hi all!

Perhaps this has been already reported, but even when automation follows events (or whatever that setting in the automation pane is called) is enabled, there are many instances where the automation doesn’t follow. For example:

  • When using ripple editing (Shift+Backspace).
  • When using “Shuffle” mode in the Snap settings.
  • When using the “Set Spacer Between Selected Events” under Functions in the Edit menu.
  • When there are tempo changes.

As far as I can tell, automation ONLY follows the events when you manually drag them. That’s about it. Otherwise it just stays in place if any of the edits mentioned above are performed. Is this intended behavior, or is it a bug?

Thanks!

I can only confirm those two:

  • When using “Shuffle” mode in the Snap settings.
  • When using the “Set Spacer Between Selected Events” under Functions in the Edit menu.

Shift+Backspace and tempo changes work ok for me.
Good finds, though.

1 Like

Thanks for checking!

I’m wondering if I’m missing something because there was a project where, after creating the automation, I accidentally changed the tempo. I think it went from the default 120 BPM to 124 BPM, and that was disastrous. I remember opening up the project and asking myself “WTF?”, only later to realize that the tempo had changed and all I needed to do was simply set it back to 120 BPM. A VERY frustrating experience, needless to say.

Also, Shift+Backspace doesn’t follow for me. I’m on the latest patch of Cubase 14 Pro, on Windows 11 (also latest patch). What version of Cubase and OS are you on?

Cubase Pro 14 and Win10.

OK, I think I know why you’re not seeing what I’m seeing in those two cases. When you tested this, you probably only had automation at the beginning of the clip, but not in the middle.

Try creating a bunch of square shaped (or any shape really) automation throughout the clip, then change the tempo. You should see the automation move. Now set the tempo back where it was to reset to normal and try using Shift+Backspace somewhere in the middle of the same clip. Again, you should see the automation go out of sync in relation to the waveform in both cases. BTW, enabling the feature that lets you visualize the event’s waveform in the automation lane will help you see this better.

Unless you have Linear mode enabled in the track, at least in the case of changing the tempo, you should see the automation go out of sync. Please let me know what you see now.

Thanks :pray:

I consider this intended behavior because it’s been this way for as long as I can remember, with the caveat that my recollection could be a little off base. I’ll explain more below.

The current behavior has a kind of logic to it though, and it makes sense (to me) once you break things into discrete events and think of things in small silos of workflows too. Slice things up into smaller events, and keep automation lanes open (and select everything on all relevant tracks and lanes) and it behaves somewhat closer to what you might be expecting, with the exception of seamless tempo awareness inside automation lanes from what I recall. I ran into issues with that for sure in the past.

If I stay inside Cubase for this kind of project that relies on this workflow (see below), the workaround I have used is extreme attention to what I am selecting, and double-checking everything. This is very very tedious. Perhaps Steinberg could improve the “automation follows events” significantly though and make it much more tempo-aware and accurate in all situations, but for now, I believe this is just the way it is. I could be completely wrong though and misremembering how things were before.

One partial NEW workaround, at least with regard to volume automation, is to use event volume curves (new feature in C14, that are obviously therefore fundamentally attached to the events), things move and scale much more logically IMO. That’s one reason why C14 was such a breath of fresh air to me, specifically this new feature. I haven’t fully tested that yet with more complex tempo changes, but from a quick test, it behaves much more logically to me, IMO.

Again, I could be wrong, but just because I think Steinberg will consider this intended behavior, doesn’t mean it’s optimal behavior, and it’s certainly not MY preferred behavior. I think it’s a holdover from a long time ago TBH. BUT perhaps Steinberg would think all this is indeed a bug though, and if so, it would then break some people’s current workflows that they rely on how it currently handles things today, so Steinberg would need to offer the option for the current quasi-broken/inefficient behavior and a “new/fixed/better/optimal” behavior. Hence why I think at this point, it is therefore intended behavior, lol.

BTW when editing complex dialog or sound design projects that have a lot of automation, tempo changes, and need lots of ripple editing kinds of workflows, for example, I do NOT use Cubase/Nuendo, since the overall workflow is too slow for me for those kinds of projects, with the aforementioned potential hiccups among other things. I have done this for years now, so this is part of the reason why I say my recollection of past behavior might be off a bit. I just know I had issues like this, and I felt a lot of frustration years ago for projects that needed these kinds of workflows. So forgive me if my recollection is not 100% accurate. I just recall this is how it’s been… but to be clear, my workaround was to jump over to Reaper, which handles all that much more intuitively IMO, at least to my workflow preferences. Cubase/Nuendo are great for what they do, but the core Steinberg workflows are not ideal for all kinds of projects.

So personally, I think the way to approach this issue is to submit a feature request for an alternate workflow, then deal with that we have today as-is, and/or possibly consider branching out to using another DAW on the side that handles those workflows better for certain projects. YMMV. And again, I could be wrong about some prior behaviors and my recollection could be off, so my whole post here could be garbage or misinformation!

BUT moreover, I do think this is probably one of the things that has been slowing down the release of true drag-and-drop ripple editing for Cubase/Nuendo, since the current behavior is frankly kind of incompatible to seamlessly dragging things around a complex timeline since there’s a likelihood that the automation will get bumped out of sync IMO, among many other things. Steinberg’s track concepts are very dense with metadata and I think drag-and-drop ripple editing will be very hard to implement 100% consistently across all track types. I believe Steinberg has to really re-engineer this whole series of interrelated workflows IMO to eventually give us the seamless drag-and-drop ripple editing that some of us have been asking for. It could be a few more years before we get that, and when it comes, I will BET there will be a lot of complaints about other broken workflows!

Just my two bits. Lots of caveats with this post. Cheers!

1 Like

Thanks so much for replying to my post!

You have given me a way to mitigate one of the issues I was having. That is, selecting the audio even alongside its automation nodes gives me the expected behavior when using Shift + Backspace. Thanks for that! Also, the idea of using event automation rather than track automation is intriguing. Need to try that!

As for the issue concerning Tempo Changes, simply switching the track time base from Musical to Linear mode keeps everything in place. Now I’m no longer worried about accidentally changing my project’s tempo and having the automation get all out of sync, so that’s great too!

However, the other two (Shuffle mode and setting a space interval) still remain. I thought about them being intended behavior, but I just can’t conceive a scenario where one would want the automation not to follow the event when the “automation follows event” option has been purposely selected. To me the way it currently works is expected behavior if the aforementioned option wasn’t enabled, but not if it was enabled. For this reason I will report them as bugs, and based on the reply I get I might summit them as feature requests.

Let’s see what happens.

1 Like

I agree it’s not ideal behavior, or even intelligent behavior, and it’s definitely not my own preferred behavior, but I fear/recall that this has been the situation for such a long time that it has become the de facto intended behavior as a result. But yes, what you are saying would definitely be better and logical. I believe it’s been so long that they may consider this as a feature request… BUT I sure hope my recollection is wrong and they will consider it an obvious bug though, and prioritize fixing it. Either way, I hope the behavior is changed asap.

:+1: Thank you for spending the time reporting this! Please keep us posted on what happens.

I do believe that no matter what, Steinberg will have to deal with all these related workflow holdover issues from the past when they eventually tackle drag and drop ripple editing. :crossed_fingers: :crossed_fingers: :crossed_fingers: :crossed_fingers:

1 Like

If I have to submit it as a feature request, I will. I’ll just give my bug report a few more days before doing so.

This being the de facto behavior for so long seem weird to me though. It literally makes no sense, lol.

1 Like