IPluginCompatibility limitations and ideas

Hello @Arne_Scheffler ,

I’ve been in discussion with Native Instrument’s NKS team about VST2 to VST3 migration.
As stated in the VST3 docs

For Automation compatibility, you have to ensure that VST 3 parameter IDs have the same value than the indexes of their associated parameters in VST 2.
Only with this condition the host can play back the automation.

This is a big limitation especially for already released plugins that use unique ID’s instead of zero-based indexes. Other formats (AU/AAX) and Juce-based plugins by default use unique ID’s which offer lots of advantages over indexes.

I believe this limitation is artificial and that it would actually be quite simple to extend the existing IPluginCompatibility / moduleinfo.json mechanism to support the unique ID variants.

Either the host can scan the VST3 and if it finds out the ID’s are non sequential, use ​Steinberg::ParameterContainer::getParameterByIndex() to perform a VST2 index to VST3 ID mapping. This should work for plugins that added the parameters in the same order in both VST2 and VST3 versions.

Another more explicit option would be to extend the .json data to contain a simple map of indexes to VST3 ID’s, or in the case of IPluginCompatibility, one could also add something along the lines of ​bool IPluginCompatibility::vst2_index_to_vst3_id(int index, uint32_t vst3_id) (returning false for invalid / out of bound indexes).

Please let me know what’s your stance on this, thanks.