This has to be fixed for current versions of both Cubase and Nuendo. NO WAY I am paying to get this fixed.
Here is the workaround for the first. This may be how it is supposed to be used and was probably overlooked because in this case, no automation has been used yet - but it appears to work for non-automated fader levels as well.
Not an ideal workaround unfortunately. They simply need to get fixed and made usable.
I can foresee in some instances where this workaround would indeed be a problem because you require the VCA to have more play room than the +6db from 0db if you are doing a big VCA controlled volume sweep.
But I’m pretty sure that would be the only instance where this workaround wouldn’t work? What are you thinking?
edit
If the above became a problem, you could probably then unlink the VCA from the channels, and then position the VCA fader as needed, and then re-link them. Haven’t tested this.
I would still just use an initial automation node instead. As far as I recall it’s solved more than one problem so it seems more “convenient” that way.
I don’t get it but I’ll try.
So right off the get go, in your templates all your tracks with VCA have an automation node at time-0 and at 0db and then… do you leave Read on, or do you take it off?
If you left it on, you would no longer have individual fader control as the faders would jump back to 0db.
If you left them off Read with the one node, then once you go to automate and Read turns on you will have to adjust that node.
Doesn’t seem very fader-tangible to me. This would maybe work if you are mostly doing event based volume editing and leaving your faders at 0.
I have my tracks in some sort of automation mode by default. There’s virtually no case where I won’t be printing automation to an area anyway so I’ve just gotten used to having tracks armed at all time.
So for example I’ll have dialog tracks set to automation enable, touch trim. Faders will rest at zero and whenever I touch a fader to adjust level it’ll be with the project playing back and me writing that automation (trim). It’ll be an offset but that’s fine since using event levels the dialog will live close to -24LKFS already after editing it.
If I ever need to adjust levels “freely” over a section it’s going to be a case where my punch-out is going to fill a range anyway, so I have a macro that adjust settings to loop playback/fill loop/preview. Then I adjust and hit a key to punch out.
My workflow is almost exactly the same in Pro Tools.
Interesting, you should do a video of how you work, sounds interesting.
That might work for post but it’s terrible workflow for music production.
Pretty much yea
Well, sort of, yes, kind’a maybe. If you want to be able to just grab faders and move them and have them stay there at least initially then of course it’s less than ideal. But then again, consider a potential workaround:
Let’s say you want to set basic levels for a song. You have a rhythm section you’re starting with (hypothetically). You pick a section of the song and play it back. You move your faders so the balance is the way you want it.
Now what? It stays that way throughout? Well, if that’s the case then you don’t need VCAs for those channels.
But let’s say that you expect levels to change between intro/verse/chorus/bridge etc. You’re left adjusting levels for those sections and printing automation to make that changes recall. As soon as you get to that point you’re engaging automation write modes and are writing automation nodes for the section in question.
So if that second scenario is the case you really have to be careful because you need to retain whatever state the faders are in as you start adjusting them for the ‘next’ section. So you need to write those first “freely set” values as well. And so as I mentioned earlier you could hypothetically then start with automation nodes and have a macro that suspends read, places you in preview mode, and sets punch-out to [to start] and [to end]. This way as far as I can see the behavior should be identical in that you can grab your faders and move them freely to adjust levels that first time (and any subsequent time you want to adjust them) and then be left with those values and automation nodes.
With that workaround, with the exception of having to press a key to enter that state as well as pressing another key to punch-out, what are the drawbacks that would make it “terrible”?
If I had a camera with a flattering filter for my ugly face I would. And I’d need to hire a VO artist so you (I) wouldn’t have to hear my awful voice…
Incidentally one other thing I like about this workflow is that with faders always sitting at unity because of touch-trim (for dialog) when working with cheaper surfaces I don’t have to listen to them moving up and down all the time. For things like music automation where moves are typically much longer I leave them in latch and it’s less of a noise-issue.
With my workflow (and many others) it’s a case of working top-down when mixing and only adjusting what is needed when it’s needed. I might have master VCA which I’m using to automate between arrangement sections and then instrument section VCA groups. I can freely adjust the balances within any VCA group as expected. If I however need to make an automation adjustment with one particular fader then it will take into account the various VCA offsets and the mix now falls apart. Writing initial node automation removes all the flexibility and speed when working so this is simply not an option.
Again, look at it from a top-down approach with nested VCAs and it’s pretty clear how broken the workflow becomes. I’ve honestly given up on trying to use Nuendo for this anymore as Pro Tools just works as expected. They should come with a huge disclaimer as to how much of a steaming pile of garbage they are though. For example, client asks for a “1dB change” in a section which creates automation and seems simple enough. Do the change, automation is now created, incorrect VCA offset is calculated, and now the mix is ruined. I had wrongly assumed that they [VCAs] actually worked and a 1dB move was doing what was expected so I’d just do the change, print, move on to the next job, and would get an email back wondering why it sounded so different now with such a small change. Of course as you can’t undo automation and have faders go back to previous positions (another issue) it turns into a case of having to re-create a lot of work and searching through backup files for a seemingly insignificant change.
Total and utter garbage.
I’m not saying that the bug isn’t nasty and that it doesn’t have nasty consequences. Of course it does.
What I’m saying though is that if you want to protect yourself from erroneous fader movements then as far as I know writing automation nodes is the only way, and in addition to that the workaround I mentioned involves two key clicks only, no more. It seems to me to be “an option” that wouldn’t really slow you down at all actually.
Just so we’re clear though, I’m absolutely not questioning your workflow or excusing the bug, just trying to find out if there’s a reasonable solution for you so you can have your cake and eat it too… and it seems to me that it’d be a bigger benefit to use VCAs with a simple macro than it is not using VCAs at all, from what I can tell…
Perhaps so but I’ve moved on from Nuendo for that task as it’s just simply not good enough and Steinberg don’t seem to have it as a priority (they’ve had years to get it right).
My guess is when they did that huge re-write of the program whenever that was (probably when VCAs were introduced), all that code is tucked deep in the foundation of the program and because they missed this, they’re essentially having to do re-write from that foundation but may’be I’m wrong. Some things you can’t fix without breaking everything else.
Honestly I think it’s probably more a matter of priorities rather than big re-writes.
Incidentally I finally got a chance to play around a bit with v10 and yeah, the bugs described are there, and in addition to that I found that enabling trim and turning it off again has the effect on controlled channels that it adds a node at the top, which is weird.
Actually, there’s more stuff that’s clearly broken when using “trim”.
care to make a gif with LICEcap?
I’m trying to figure out just how much I care about this at the moment. I’m just demoing v10 so it makes sense to test stuff, but on the other hand I feel I need more work specifically on Nuendo for me to care more…
Anyway, if I have time this week I’ll find repro steps and an explanation of what I think is proper expected behavior and then see if people can repro. I think it really makes sense at this point to come up with all scenarios of working and then compiling them into a list of steps to test on new versions, you know… just rip through a long list and check off stuff that I/we care about.