āsome valueā? Iād say thereās more than just āsomeā value.
Good for you.
I bet you that the vast majority of Cubase and Nuendo users that donāt use it never used VCAs in the first place. In other words, they never used it on either consoles or Pro Tools or similar. So as with a lot of other functionality they might not āgetā the need for or benefit of using them.
It might be nice if there were a thread here that detailed specific problems people were having with VCAs, and possible workarounds, if any.
There seems to be a lot of āVCAs are brokenā with few specifics.
Such a thread would give those of us who use them things to look out for and temp fixes - until such time as Steinberg works out the issues . . . which Iām certain will be the VERY NEXT maintenance update cause theyāre so on it . . .
Who knows, it might even light a bigger fire.
If such a thread exists please direct me . . .
Hugh
In a nutshell, Steinberg donāt seem to understand how VCAs work and while they are aware of the issues, they are obviously not a priority considering theyāve never worked properly since their introduction. If you use VCAs by themselves without any automation you might assume things are okay but as soon as you add automation into the equation, good luck!
Hereās a really simple example:
- Create one audio track and 1 VCA fader (both at unity)
- Link the audio track to the VCA (both faders still at unity)
- Reduce the level of the VCA by -12dB (both faders now at -12dB)
Now, what if you want to add 3dB of level to a particular section on your audio track with some automation? Logically youād expect that your audio track should be at -9dB for that section with the rest of the track still at -12dB. What happens is your actual level is now at -24dB with -21dB (for the +3dB section) as Nuendo compounds the VCA and track offsets before applying automation. You can see how this can destroy a mix if youāre not aware of how buggy it is.
The fundamental misunderstanding on Steinbergās side is that VCAs should simply provide an offset. In the above example, if I disconnect the VCA my fader should jump back up to where it was originally (unity) as the offset is not being applied anymore but of course that wonāt be the case. There are other examples but that one is easiest to see just how fundamentally broken they are. Pro Tools of course works exactly how you would expect.
Could not agree more. Thank you for bringing this up. Looking forward to it.
Bugs and their workarounds have been a constant part of life since I bought an Atari St in 1987 and programmed my first hit record without any Live players.
Iāve been completely inside the box since 1999 I never have used Pro Tools in the process. Just not a fan although it is so much better than it used to be.
My point is Iāve kind of seen and done it all. Never have waited for Developers to comply with my wishes in the future. Find the best tool and then find the best workarounds to make it your own in spite of the things but are not to your preference. Workarounds have been, are and will be a fact of life. I wholeheartedly agree that aspecific VCA workaround thread would be brilliant.
I would nominate MattiasNYC kick it off if he would since I think he knows more about this than anybody else at this point. Possibly even Steinberg! hehe
The problem with those VCA bugs, is that solving them would probably produce some level changes in mixes that have been done with VCAs in previous versions. Not sure about that but it is probable.
This is probably one of the reasons why they are still not fixed.
A solution would be to propose a new automation engine, and select it for new projects, but keep the older engine for projects saved before the new engine introduction.
A new automation engine should allow as well to give a chance to introduce an object oriented automation as opposed to the actual (i consider it legacy) track oriented engine.
Not seeing -24dB with -21dB here. I see -12dB and -9dB. 
What am I missing? How do you make that happen?
Actually, I donāt think thatās necessarily true though. From what Iāve seen most issues have been happening when the user has done something and the result was clearly wrong. So it seems to me that loading up an old project with āwrongā automation should work fine and that the user probably wouldnāt notice something āoffā in the new project until actually using the VCA/connected tracks. But that āoffā in the newer project would then be correct functionally.
I could be wrong about this, but thatās how it strikes me.
Imgur: The magic of the Internet and also thereās this one which wrecks mixes too Imgur: The magic of the Internet
Iāve confirmed both still happen exactly the same in 10.1. Hereās Pro Tools which works exactly as expected - https://imgur.com/a/kZoc7rx
OK got it. I can repro this and the other one too. The strange thing is if you use the audio channelās fader to write the +3dB automation this problem does not occur (this is what I was doing). So the problem occurs when you use the automation editor or write new points on the automation trackā¦ very odd behaviour.
If you have an initial start point then you should be okay but if the track contains no automation then you should get one of the other behaviors. Using the fader using punch preview will result in the incorrect offset.
Itās not just odd behavior but itās downright dangerous if youāre not aware of what itās doing. Iāve had mixes where clients have asked for small changes on tracks with no automation not realizing that in doing so my entire balance was ruined. Thankfully there are other DAWs where this works as expected.
Ok. Anyway itās always possible to manage an engine change. It has been done in many softwares, for example Capture One in the photography world, where regular raw development engine changes have been implemented.
When opening an older project, it is asked to the user if he wants to convert to the new engine. Simple and efficient.
Using this technique, it is even possible to drop the older engine support in new software releases. Then in this case the user has no other choice than converting the project to the new engine.
The problem here is that
a. this has been around since vcas have been introduced, so arguably the feature is still unusable after 4 years
b. the result of this bug is so serious, it is not something you can risk forgetting to work around.
The more i think to that, the more i think that an automation engine change, with previous projects conversions would be the safer solution.
It would clearly isolate previous mixes from unwanted level changes, and would allow to implement a fully new engine, specially an object (event) oriented engine that would be welcome to catch up with competition.
Track oriented automation is something that tends to prevent sound designers from making easy dynamic changes and easily move events in mixes in a error free context. The track automation technique according to me is clearly something of the past, coming from the tape machine world where it was not possible to move audio events.
When working with a software that do allow object oriented mixing, it is a hassle to come back to a track oriented automation software.
DOP should never have been implemented. It should have been implemented as a true event oriented automation engine (event online processing), with offline processing (DOP) as an option to freeze automation on events that do not need anymore dynamic automation - to free up resources.
Another advantage of doing that instead of fixing the old engine, is that it is sometimes desirable to rewrite code instead of modifying it, specially when it is old complex code eventually badly structured or badly commented, or when original programmers dead leave the boat in the meantime.
If those VCA bugs have not been fixed since 4 years again i think that there is a reason and a radical decision is needed now for Nuendo 11.
I was just thinking the other day that I keep doing this out of habit at this point, because surely the problem has been fixed by now and I just havenāt noticed it in the release notes! Crazy that this is still an issue.
Well, I had campaigned for object based automation for at least a decade here, at no avail. Interestingly PT automation (although track based) works so reliable that you can use it as plugin snaphot automation per clip with 100% reliability, something I had hoped/asked for for a very long time in Nuendo.
Well weāll hopefully see at some point whether a rewrite that isnāt directly backwards compatible is required or not. Iām hoping it isnāt of course.
I think āaā follows from ābā actually. So for someone who is acutely aware of this and sets up templates with pre-existing automation points and also keeps an eye on things then VCAs are usable. But youāre right, for a new user this is not good.
At this point Iām thinking that even an āuglyā workaround in programming might suffice. Clearly thereās something wonky with the logic at some point, but perhaps the programmers workaround is to simply always write automation points regardless of the status of the slave channel. In other words in the examples shown earlier here instead of just lowering the āfaderā of the slave track also then write an automation point at the beginning of that track.
Of course there are probably implications of that which will be annoying, but itād arguably be equal to the manual workaround we need right now anyway (automation point written by us),and what weāre really losing is I suppose āvirgin territoryā which Iām guessing many arenāt using (and I have my opinions about its implementation as well).
Like I said, I think thatās probably a pretty āuglyā solution, but maybe thatās one way of going about it. I could have missed something of course, Iām only on todayās first cup of coffeeā¦
No more bandage workarounds please. They are fundamentally flawed and are also lacking in functionality compared to what Pro Tools does with VCAs.
Just tear them down and get them right like they should have been done 4 years ago.
Yes and Yamaha know that it is a very sensitive subject - for example because of this locked thread :