Hello JUCE users,
Following Steinberg’s announcement that they are removing the VST2 components from the VST3 SDK
the JUCE team is also removing the VST2 header files from the JUCE repo. As of this commit
it is no longer possible to create VST2 plug-ins using JUCE’s embedded VST2 SDK.
If you are an existing VST2 developer, with the prerequisite VST2 developers license from Steinberg, then you can use the VST2 SDK from an older version of the VST3 SDK (or JUCE’s git history) to continue building VST2 plug-ins. If the VST2 SDK is in your compiler’s header search paths then no further changes will need to be made to your project.
Aside from missing header files there is one additional complication. By default JUCE automatically created VST2-compatible VST3 plug-ins, where both versions of the plug-in shared exactly the same form of saved state. This meant that some elements of the VST2 SDK were required to build VST3 plug-ins, and that the VST3 plug-in could “override” a VST2 plug-in in supported hosts. So if you’re currently building a VST3 plug-in you will also need a VST2 SDK to compile your project, even if you’re not building a VST2.
JUCE_VST3_CAN_REPLACE_VST2 configuration option has been added to the Projucer. This defaults to
1, meaning that existing projects will be unaffected by this change (aside from requiring a VST2 SDK), but this option will be set to
0 for new projects. When this option is set to
0 then the VST2 SDK is not required to build VST3 plug-ins (which will work out-of-the-box with JUCE) but plug-ins built in such a way will not be able to “override” VST2 plug-ins. Changing the
JUCE_VST3_CAN_REPLACE_VST2 option changes the form of the plug-ins saved state, so any previous state saved in a host by an older version of the plug-in will be incompatible. This means that hosts will fail to load the new version of your plug-in on an existing track. Therefore, leave this flag unchanged if you want to maintain backwards compatibility.