Am I correct that identifier meant in “The Plug-in has to assign a unique 32-bit identifier to each exported parameter.” is ParameterInfo::id, and that this ID is supposed to be used by host software to identify parameters for automation?
Am I furthermore correct that the index of the parameter (as shown by e.g. VST3PluginTestHost) is not supposed to identify automatable parameters?
That is, as a plug-in developer I can change the order of parameters as I please - as long as I keep the IDs unique and identical between builds?
Yes, parameter ID is a unique identifier inside a plugin, exported to the host. The host uses this ID for automation mapping (automation curve => parameter ID) or remote control mapping (physical knob <=> parameter ID)…
For keeping automation compatibility between different versions of the plugin you have to use the same ID for given parameter if the meaning of this parameter has not changed, else you have to use a new ID for it.
The order of parameters has no influence on the automation mapping, only the UI-presentation of the parameters will change (depending on the unit structure too)
In VST2 versions of my plugin(s), the parameter ID was basically the index in my internal parameters list. But in the VST3 version I want to change that ID to a hash value representing the parameter’s string id (hash of “L1.f1.fc” for instance). Now the big question is, would that break compatibility with existing automation curves in users’ projects ? Is there a way to prevent that?
Up to 2^31 parameters can be exported with ID range [0, 2147483648] (the range [2147483649, 429496729] is reserved for host application).
By changing the IDs you break the automation, you could add the old parameters (for playing the old project automations), you have then a problem when the user will write new automation: use the old id or the new? not perfect.
As far as I remember, in VST2 we didn’t have the notion of parameter ids, instead we had parameter indexes (please correct me if I am wrong). Parameter Ids are the right way to do it. But to be able to use them I need to change indexes to Ids in VST3 version of the plugin.
It would be great if the SDK supported a way of mapping old VST2 parameter indexes to new VST3 parameter ids so that existing user projects would not break. Adding the same parameter twice with the index value and id value is not a good solution as you say Yvan.
I actually think that using indexes for parameter IDs is not bad. I would just continue to do so. The good thing is that you can order the parameter list differently with VST3 and you don’t have to rely on a structure that may have evolved over time.