// If you encounter this error there may be an issue migrating parameter
// automation between sessions saved using the VST2 and VST3 versions of this
// plugin.
//
// If you have released neither a VST2 or VST3 version of the plugin,
// consider only releasing a VST3 version and disabling JUCE_VST3_CAN_REPLACE_VST2.
//
// If you have released a VST2 version of the plugin but have not yet released
// a VST3 version of the plugin, consider enabling JUCE_FORCE_USE_LEGACY_PARAM_IDS.
// This will ensure that the parameter IDs remain compatible between both the
// VST2 and VST3 versions of the plugin in all hosts.
//
// If you have released a VST3 version of the plugin but have not released a
// VST2 version of the plugin, enable JUCE_IGNORE_VST3_MISMATCHED_PARAMETER_ID_WARNING.
// DO NOT change the JUCE_VST3_CAN_REPLACE_VST2 or JUCE_FORCE_USE_LEGACY_PARAM_IDS
// values as this will break compatibility with currently released VST3
// versions of the plugin.
//
// If you have already released a VST2 and VST3 version of the plugin you may
// find in some hosts when a session containing automation data is saved using
// the VST2 or VST3 version, and is later loaded using the other version, the
// automation data will fail to control any of the parameters in the plugin as
// the IDs for these parameters are different. To fix parameter automation for
// the VST3 plugin when a session was saved with the VST2 plugin, implement
// VST3ClientExtensions::getCompatibleParameterIds() and enable
// JUCE_IGNORE_VST3_MISMATCHED_PARAMETER_ID_WARNING.
I have already released a VST2 and VST3 version of my plugin with JUCE6 and JUCE_VST3_CAN_REPLACE_VST2=1 and JUCE_FORCE_USE_LEGACY_PARAM_IDS=0, and now I am migrating to JUCE8 and get this warning.
With this warning, I don’t understand whether I also have to implement getCompatibleParameterIds(). It worked before (with JUCE6), didn’t it? Or are there specific hosts that cause problems which rely an a specific getCompatibleParameterIds() implementation?
JUCE_VST3_CAN_REPLACE_VST2 ensures that the VST3 plugin can be identified as a valid replacement for the VST2 version, and so any data saved using the VST2 version will be handed to the VST3 version which should load all the correct initial settings. However, if any parameters have automation data they will have parameter identifiers attached to them. If the identifiers of these parameters are different between the VST2 and VST3 versions, the automation may not work. This is what happens when JUCE_FORCE_USE_LEGACY_PARAM_IDS is not enabled. Some DAWs (Reaper for example) appear to have worked around this and will normally work, although if you have since added/removed or changed the order or ID of any parameters that strategy might fail too.
So in this case you should implement getCompatibleParameterIds() for maximum compatibility. This allows a DAW to identify the correct parameter to automate given a parameter ID.
The best DAW to test this with is Cubase. First try the following.
Install the VST2 version of the plugin
Create a session with the VST2 plugin
Add automation data to the session
Save the session and quit the DAW
Remove the VST2 version and install the VST3 version
Open the session
I would expect the session to load correctly using the VST3 version, however automation data will likely fail to control any parameters.
Once you implement getCompatibleParameterIds(), as long as you’re testing with a modern version of Cubase the automation data should work correctly. I can’t remember the exact version they implemented this, so just try the latest version.
If you take a look at the docs for getCompatibleParameterIds() you’ll see an example of what the implementation might look like when JUCE_VST3_CAN_REPLACE_VST2 is enabled and JUCE_FORCE_USE_LEGACY_PARAM_IDS is disabled.
Thanks for clarification.
Should be pretty easy to implement, because I never ever change the index of a parameter anyway.
(Which is what I actually thought, that it is also a requirement for automation lanes to be compatible with each other between two VST2 plugin versions).
(I guess that’s also the default lookup method, cause no user has ever reported an issue with is.)
(Which, of course, worries me a little to implement getCompatibleParameterIds(), because normally I don’t “fix” things that aren’t broken.)
It is between two VST2 versions, however some manufacturers have moved away from VST2 but they just want their VST3 version to correctly replace the VST2 version in a session that was originally saved using an older VST2 version. IIRC this is especially important on modern Macs, as the Apple Silicon version of Cubase no longer supports loading VST2 plugins.
Please do check but I think you’ll find this is a problem for you, the most likely case for an end user to see this is probably with Cubase, especially if you are still installing the VST2 version because in that case most DAWs are probably still loading the VST2 version and so there won’t be any compatibility issues.
