Poll V11 #2: Removing automation backwards compatibility

[DarkStar]

well, yeah, but this is just for backwards compatibility....

so, if the user already has automation to, let's say, the gain of eq band 3, and that's (say) ID 41.

you can make this still work by making the tool come up with the first 100 parameters now the multiparameters mapped to those parameters - i.e. ID 41 is now a multiparameter that is controlling the gain of EQ band 3, and the automation still does what the user expects.

I didn't think that a plug-in can 'ask' the host for the Ids of the parameters that were automated; if it could then the parameters could be automagically mapped to Multiparameters (MPs) as you said. That would be great. I was expecting to do that mapping myself.

obviously, if the user tweaks EQ band 3 manually, this will get out of sync (because the multiparameter no longer matches the actual parameter value), but old sessions will still work. and probably in the GUI this would be a little more obvious.

That has been the case for parameters and MPs for some time.

but that brings up another question... how does recording automation work with multiparameters? now, they are explicit, but e.g. if I want to record changes to gain 3, the few times I've done it I just grab the gain for band 3 in the GUI and change it, and the automation records it. today, if I want to change a multiparameter, of course I can do that, but in this model there aren't that many 'normal' parameters left - i'd have to use a multiparameter to change the gain on band 3, and in that case, will the GUI make sure that this workflow still does something useful?

Correct, twiddling the Band 3 Gain would not communicate any automation info to the host; you would need to twiddle the appropriate MP.

--------------------------------------------------
Let me repeat my questions:

So that we do not have to rush, is there anything we can do to prepare for the v11 Automation?

-- Will all plug-ins (except the ones in the Free FX Bundle) get the "100 automation parameters"?
-- Do I understand correctly that all existing parameters will still be available in the Multiparameter and Modulator windows, for selection?
-- And that all existing parameters will still be available in the MIDI Settings / Controllers and Notes (and, therefore, could still be automated using MIDI CCs/Notes)?

[chroma]

I didn't think that a plug-in can 'ask' the host for the Ids of the parameters that were automated; if it could then the parameters could be automagically mapped to Multiparameters (MPs) as you said. That would be great. I was expecting to do that mapping myself.

AFAIK, the host doesn't know the name of the parameter - it's by #. this is why VST writers are so loathe to add/remove parameters once they get installed bases... the host only knows that you're automating lane#41, and that if they ask the VST for what lane 41 is called, it's something like 'EQ Band 3 Gain', and the VST can even return the proper range and string representations of the value (so a value of 400 might be -2.3db or something; this is how something like a Remote SL can show 'normal' values for some things).

later, if the VST decides to add a parameters and now ID41 is 'EQ Band 3 Frequency', the host will still happily send value 400 to lane#41, it just means something different now; the host has no way to figure out that it changed.

but (i think) if the actual parameter changed to be 'Multiparameter 41', but it happened to be named 'EQ Band 3 Gain' and was connected to the EQ Band 3 Gain parameter internally, the host would still send the 400, the vst would route to the right place, and the end result would be the same. if the user later decided to change the MP to something else, they still could though.

obviously, if the user tweaks EQ band 3 manually, this will get out of sync (because the multiparameter no longer matches the actual parameter value), but old sessions will still work. and probably in the GUI this would be a little more obvious.

That has been the case for parameters and MPs for some time.

It's always been the case for MPs (and Kontakt works similarly). it's just that workflow is more of a pain in the *#*$ than directly grabbing the the parameter. the difference is that today, i have a choice - if I grab a parameter, it works, but if I want to use the MPs instead, I can. it sounds like that's no longer the case... you have to use an MP, and the simpler workflow won't be available anymore.

[pone]

Vst parameters are simply kept in an ordered list. When a daw changes a parameter, it only cares for it's index number. A parameter has a value in the range of 0-1. Vsts can supply a name and a value string for that parameter, the daw only displays it and does not interpret it.
As said in the thread by Vojtech, this will affect only plugins with easy screens (this includes autodynamicEq, dynamiceq etc.. No free plugins and no plugins that are not expected to be automated (for example freeformeq and linearphaseeq) will be affected.
And there will be backwards compatibility as many have expressed their unhappiness with the change.

[valsolim]

AFAIK, the host doesn't know the name of the parameter - it's by #.

Actually, at least for VST3, the host does know the name of the automated parameter. However, one thing is necessary: after renaming the multiparameter, the plugin needs to be reinitialized - which can be conveniently done by pressing the "!" button in Melda plugins I have verified this function in Cubase 8. (Of course, re-opening a project reinitializes all included plugins as well.)
--
Miloslav

[MeldaProduction]

It actually depends only on the host. Sadly there's just no standard in that... nobody knows if the host will identify parameters by names or indices, what will happen if you add some, what will happen if you change the name... it's a mess .