Cursor Position woes with Automation, Virgin Territory at fault?

I have this situation.

This is the start of a project. I have all sends to the reverb up, and then I bring them down to -inf. at some point. They never come up again during the song.

This is towards the end where I have left it off for the time being. Now, here’s the deal:

If I play for a bit from that point between 41 and 49, and then I go to Export, the first bars up to the automation I’ve circled in red in the first screenshot ARE DRY. The sends kick in at exactly the point where automation dictates, and they go to -inf.

This is unexpected behaviour, and I wonder if someone knows what’s up. (I have an idea, but I don’t want to prejudice anyone)

On the other hand

If I tick “Update Display” in the Export Audio Mixdown window, everything exports fine, no matter where I’ve left the cursor.

Thoughts?

1 Like

Should I try to bake this into a stock mini project so that others can try too? Is this description clear enough?

export test project.cpr (1.1 MB)

Here’s a test project, I’ve included some notes in the Notepad. Please see if you can reproduce this.

I don’t quite get this part. If the reverb sends are at -inf wouldn’t you expect all tracks to be dry?
And in what way do the sends kick in when you wrote that they are only up at the beginning and at -inf for the rest of the song?

Hey, Johnny, thanks for dropping by!

The initial parameter is 0 for each send. Then, there’s virgin territory. Then at bar 9, an automation point exists at zero, and a line is drawn to -inf. So when we play the project from the start, it starts wet, as it should be, then at bar 9 reads the automation, drops to -inf and dries out. That’s what should happen.

But, when I park my cursor to a later part of the song, play a bit, stop, and then immediately go to export, IF the Update Display option isn’t ticked, the first 9 bars come up DRY, and the wet starts at bar 9, which is the first automation point.

It’s as if the initial parameter is not read. (But I’m not certain this is the explanation)

Ok, makes more sense now. I’ll have a look tomorrow, gonna tuck in for today.

Updating the issue. This is not an export issue.

To reproduce, grab the project I’ve posted above and do the following.

  1. Place the playback cursor to bar 10, by clicking on the main ruler.
  2. Play using space for about 1 bar.
  3. Manually place the cursor to bar 0, by clicking on the main ruler.
  4. Play using space for about 2-3 bars. Listen to the drums closely.
  5. Place the playback cursor to bar 10, by clicking on the main ruler.
  6. Play using space for about 1 bar.
  7. Manually place the cursor to bar 1.
  8. Play using space for about 2-3 bars. Listen to the drums closely.

My results:

When doing steps 1-4, the drums at step 4 sound dry.
When doing steps 5-8, the drums at step 8 sound wet.

Can anyone else reproduce this?

Edit: Here’s a gif showing the issue. Sorry for the speed, but I can’t do it slower because it will go over 4 MB and won’t allow me to upload. Open in a new window to see better.
Virgin territory locate cursor issue
And the project, again.
export test project.cpr (1.1 MB)

Confirmed, here. Indeed, there is something wrong in the automation behavior, but I suspect the “virgin territory” to misbehave. I always avoid any use of the latter when I use automation : I got some issues with them in the past - don’t remember the contexts, honestly. In this case, when I change the automation to this (simply by cutting the initial automation point) :

… it ALWAYS works as expected, using your 1 to 8 steps… :neutral_face:

1 Like

Thanks a lot @cubic13!

Yes, that would be expected, since the data is constant. But with the initial point, it’s weird. Notice how the value IS actually read? When you park the cursor to 0, the send says 0dB level. Great! Then you play, it’s dry, and it still says 0dB level! It’s only when the next automation event is reached, at bar 3, that the send wakes up and signal gets through. At 2.4.xxx 0 dB send was sending no sound, and at 3.1.1.1, the 0 dB send actually starts sending.

When I need to automate levels with the faders, I use the “To Start” “To End” options, so that I set a rough static mix level, and then take it from there. Since the whole track is then filled with automation data, it’s fine. But for parameters, I don’t use it often. I just touch at the places I want. But this is a big deal, especially with VSTi. I can’t just write “To Start” and “To End” for 100 parameter plug-ins, surely? I just want to touch the parameter relative to where it was, from the preset’s initial values. But this issue makes me distrust my tool, and that’s really bad.

Maybe I should disable virgin territories too and see what I can do. It would be nice if this was fixed though.

1 Like

Yep, I see your point, especially when VSTis parameters are involved, as I must say that I mainly use automation for either fader or send levels. So, I’m surely not an automation specialist. But, if I remember well, the “virgin territories” and “gaps” behavior is also dependent of what we set in the Automation panel content. Worth a check, maybe…

This said, I’m going to look more closely at this, also using VSTis, and report back if I found anything useful… :slightly_smiling_face:

1 Like

Thanks, Cubic!

1 Like

I have added some automation to the lane…

…to bring the send level back up to -10dB. I then let the project play back beyond the last point of automation.
The result is that when I play the project from the beginning the send level is shown to be 0dB but is in fact -10dB (the last value set during playback).

So either the value display on the automation lane is bugged or the audible send level. Both should show and so the same thing but they do not.

BTW - I am going with @cubic13 here: I never use virgin territoy and I don’t ever use Terminator automation points because I always predicted I’d run into exactly this problem. Another area where Cubase cannot be trusted.

I do excatly that. This way automation always shows me what’s really going on. It’s my default automation mode.

1 Like

Thanks for your contribution Johnny!

I don’t know. To me it looked familiar to the VCA bug, that also seems to be affected by cursor relocation (different values at different places are read, when they shouldn’t), but, honestly, I can’t say for sure.

So, let me get this straight, because I’ve never tried it. You enable write for the instrument, “To Start” from the automation panel, and then you just let it play for a second from the beginning? And this is supposed to write all current states of the instrument’s parameters onto their automation tracks?

Edit: Lol, now I’m just fooling around. If I move the inital automation point 1ms to the right, it works fine. It’s the absolute “0” position that spoils the whole thing. It’s as if 0 is no man’s land and no parameter is allowed to be read there.

No, not quite. Just the default automation behaviour. I just create automation data, then there will be a starting value to the left of it and a continuous value to the right of it. You can see the automation line being horizontal.

1 Like

Ah, ok. So the parameters are there by default. Thanks!

Just for the record: This was discussed back in 2015 and I pointed out why the behavior with “virgin territory” is somewhat counter intuitive. The software basically reads automation points when you “locate” on the timeline, and by “locate” I mean stop playback or click to locate in the timeline while stopped. I think it reads preceding automation points, but I forget. It’s not intuitive.

I don’t think it’ll change - it’s by design. So the only way to guarantee that you get the levels you want for any given section is to make sure you have automation written there. That is basically ‘best practice’.

1 Like

@MattiasNYC, I was hoping you would find time to comment. Thank you. I know you have experience with this “virgin territory” feature both in Cubase and Nuendo.

I don’t find the feature unintuitive. The thing that’s been bothering me all day is: How can it be that a parameter is read, the GUI elements correctly follow the parameter, but no signal is passed along?

And furthermore:

This is even wilder. So in essence, the very very very simple workaround for this is: “Never play a project from the very beginning. Starting even just 1 tick to the right will make things right”. Just as a simple fix for the VCA conundrum is to “write automation for the linked Audio tracks”. But I can’t stop thinking if there are more implications / consequences stemming from this behaviour.

Ah sorry, perhaps I missed something in the discussion…

Well, here’s the summary:

  • I did an export that did not agree with the mix. Erroneously assumed it was something export related. Asterisk 1 here.
  • Kind @cubic13 and @Johnny_Moneto tried out the test project and steered me to the direction of “Virgin Territory” being the culprit.
  • Indeed, it looks like this behaviour is specific to “virgin territory”.

However.

  • Asterisk 1. What’s so special about the export option “Update Display” that makes the problem go away, when ticked?
  • Why does the project play correctly when started just a tick to the right, off the initial automation event and on the first available space of virgin territory?
  • Why is the very very start of the project special in the sense that parameters set there WILL be followed in Cubase’s GUI but not realized in the audio path?
1 Like

I made just two more tests :

  • After doing more or less the same as you (moving the first automation point from 0.1.1.0 to 0.1.1.1 with the info line) does also the trick, here : the virgin territory no longer cripples the send automation read.
  • Another one : activating the cycle read and letting the cursor go to 13.1.1.0 and return back also allows a normal automation read, this, even if the starting automation point is at 0.1.1.0.

At this point, I’m wondering if the virgin territory is still the culprit, in this case… :face_with_raised_eyebrow:
More tests to come. I’m going to look more closely at the Automation panel content…

1 Like

My thoughts exactly! Big thanks, cubic! The more clues we gather, the best our chances to get to the bottom of this.

1 Like