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”?