And another one : activate the pre-roll and set it to 0.0.0.1 : the automation is also read correctly… 
It more and more looks like as if Cubase automation needs to be warmed up, even for a millisecond or a tick, to work as expected…
1 Like
Those are the results when you have bugs and you add features on top before you fix them.
It reminds me of one bug i discovered back in the day which i still present and probably has the same root bug with the one you discovered 
Tempo Track Null Test Bug?
My advice would be: don’t bother with virgin territories, VCAs etc those were never rock solid side of cubase.
1 Like
Ahhhh, that’s a nice one! 
Well, ok, but these are useful, it’s difficult to resist. For virgin territories, I like that I can touch the faders wherever I like and write something. As for the current value, it makes sense that the fader is where I last moved it. It suits me, apart from this weird thing. VCAs, I can’t say I’m using them much, but I don’t know, maybe if I get my buddy to track some drums, maybe I could have some use for them later on when mixing.
So my intention is: Learn the quirks as much as possible, so as to avoid the most critical ones and use the booby-trapped featiures somewhat safely.
Indeed, but in the end it’s workflow preference, I am more into technical things (less in creative) and those stuff and quirks costs me numerous troubleshooting hours, also “flanging” in parallel processes due to that sample starting point shift where phase should be cancelled i got phaser effect lol. Solved those headaches with 3rd party plugins as well as staying away from uncooked features.
1 Like
Teeny weeny bump, in case anyone else has an idea of what’s actually going on here.
Skimming through this discussion, it reminds me of similar issues I’ve had with automation in the past, and here’s what I ended up using as a best practice to skirt around many of these issues:
For any automation track, I add an automation point at the very beginning of the project (at whatever value I expect that automation value to be there) - even if that means “duplicating” the automation value from later on in the project.
I add an automation point at the very end of the project (at whatever value I expect that automation value to be there) - even if that means “duplicating” the automation value from the previous automation point in the project. I make sure that this very last automation point is well after any reverb tails have died off, and I make that automation point the terminator.
This is a hassle, but it significantly reduced mysterious automation glitches. Hope this helps!
1 Like
Thanks Timo00!
The point of real interest (for me) in this particular case is that even though automation seems like it’s being followed (e.g. send levels DO follow the automation values), the signal path does NOT follow. This is truly a wonder. Moreover, while this behaviour DOES affect an export (e.g. you get something different caught in the export file than what’s supposed to be happening in the project), ticking the “Update Display” box before export makes everything right.
So:
1 ) Why does this happen in the first place (automation showing one thing, sound doing another) and
2) What magic does the “Update Display” box do to rectify things?
From the manual:
Update Display
Updates the meters during the export process. This allows you to check for clipping, for example.
So, how does this help with the issue? It seems irrelevant, and yet, it fixes an otherwise broken export.