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.
I’ll respectfully disagree about trying to fix a fundamentally flawed VCA concept. Clearly there are just too many underlying issues with VCAs and automation so it needs a rewrite on stable code rather than band-aid patching the current disaster.
You and I actually have no idea what the problems really are. I’m not convinced it’s conceptually flawed at a fundamental level, at least not the way I understand those words.
I honestly don’t really care how they solve the things I see here and for other types of automation as long as they’re solved. I also don’t think they’ll go back and redo this particular code. They might of course but I don’t think they want to if a fix is a reasonable alternative from their perspective.
Let’s put it another way. If it was an easy fix it would have been done and fixing one thing wouldn’t break another. Right now it’s a band-aid bunch of fixes on a fundamentally flawed concept and you know as well as I do that VCAs have also never worked properly since their introduction. Whoever designed the VCA spec I guess doesn’t quite understand how they should work or it wasn’t communicated to the programmers correctly. How the automation works/was designed also did not take into account having VCAs and trying to add those on top of what is there breaks many things.
Cubase 10.5 is here, don’t have time to test -perhaps they did some work on VCAs? perhaps not, haven’t seen any mention, but they usually don’t include bug fixes as part of their release highlights.
No change with VCAs in 10.5.
I just tried this in v10 and I cannot reproduce this.
I just tried in 10.2 and I can reproduce it easily.