Managing parameter IDs when porting VST2 to VST3

So in the documentation it says.

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. The parameter value has the same meaning in VST 2 and VST 3 .

However, is there any way to deal with a situation where a developer has already released a VST3 plugin which can replace a pre-existing VST2 plugin but the parameter IDs are different?

If the developer changes the parameter IDs in the VST3, sessions containing automation saved with the older VST3 version will no longer work.

If the developer doesn’t change the IDs, then sessions containing automation saved with the VST2 version continue not to work.

Due to an unfortunate set of circumstances some JUCE customers may find themselves in this situation, and other than warning them I can’t see a way we can help customers in that situation.

If there is a possible workaround I would be interested to know.

It’s worth noting that the problem only shows up in some DAWs, Reaper for example manages to match parameters even if the IDs are different. I would guess it’s falling back to using the parameter name when it can’t find a parameter ID, but I don’t know for certain.

I’m sorry, but there is no way defined in the SDK to iron out this mistake.

But maybe this:
As long as the plug-in did not define an ID with its already released VST3 plug-in which would be the index of the parameter in the VST2 plug-in, he could add the VST2 plug-in IDs and map internally the old index to the new ID.

Thanks @Arne_Scheffler I thought that was probably the case but good to clarify.

Just to explain why I’ve raised this.

In JUCE users can set JUCE_VST3_CAN_REPLACE_VST2. However, by default projects also add parameters for all plugin formats (except VST2) using an ID generated from a string that the user supplies so that later users can change the order of parameters or add new ones without breaking automation for all the other parameters. Users can disable this behaviour and revert back to the way things were previously done in JUCE by enabling JUCE_FORCE_USE_LEGACY_PARAM_IDS. This will mean the index of the parameter is used as the parameter ID, for all formats.

Unfortunately some vendors have released plugins in which they have enabled JUCE_VST3_CAN_REPLACE_VST2 but not enabled JUCE_FORCE_USE_LEGACY_PARAM_IDS. This means the VST3 and VST2 builds will have different parameter IDs.

Ideally JUCE should’ve been preventing users from doing this or at least warning users, and obviously going forward JUCE will make an effort to detect this situation and warn users, but unfortunately we already have vendors in this difficult situation.

@Arne_Scheffler how would you and the team feel about us (the JUCE team, with support from impacted vendors) proposing an extension to the VST3 SDK that resolves this issue? I realise there would be an element of waiting on DAW manufactures to implement such an extension but it seems if we could get something into the official SDK there is a greater chance of adoption which in the end is the best resolution for end users.


@anthony_juce , please send us your proposal . I will send you the e-mail address in a private message.

1 Like