Thank you for the clear documentation of the new ‘version hint’ flag.
As mentionned, it is needed for the AU because :
Logic Pro and GarageBand have a known limitation that causes them to use parameter
indices instead of IDs to identify parameters. The effect of this is that adding parameters
to a later version of a plugin can break automation saved with an earlier version of the
plugin if the indices of existing parameters are changed.
Correct me if I’m wrong, but I believe we have the same ‘indices ordering’ issue for VST2 plugins.
Is it possible/planned to use that same trick to order the vst2 parameters?
Unfortunately there’s no mechanism in the VST2 API to specify a parameter ordering that is different to the indices.
I was thinking you could eventually have an intermediate parameters container in which the parameters would be ordered taking into account both their original indices + the version hint.
A param that we would introduce in the middle with a versionHint of 2 would thus be moved to the end of the intermediate container (assuming that the other params have a versionHint of 1).
So the ordering would still be done by indices in the end (i.e. the indices of the params in that intermediate container), and the automations would not break anymore.
But I don’t know much about the vst2 wrapper internals, so perhaps my suggestion doesn’t make sense… sorry if that’s the case !
Something along those lines might be possible, but I’m not sure that all the extra complexity, and a potentially breaking change, justifies the ability to reorder parameters in a flat list without any extra grouping.