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.
A 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.
I hope you’ve let Steinberg know that removal of the VST2 SDK from future releases of the VST3 SDK will break this backwards compatibility and strongly urged them not to do that (I suspect they want to as part of this gradual sunsetting of VST2). Allowing developers to provide customers a frictionless path from VST2 to VST3 is surely in everybody’s interest.
In the Projucer, if ‘VST (legacy)’ is selected exclusively under Plugin Formats, it would be useful if the VST3 SDK Folder (containing the VST2 SDK) could be set in the Exporters.
At the moment, the ‘VST3 SDK Folder’ entry is only available if the VST3 plugin format is selected as well.
From my understanding you have to forget the notion that the 2 SDKs used to come together and as the op says, you need to add the VST2 paths to your compiler header search paths in Projucer.
The VST2 SDK can be obtained from the vstsdk3610_11_06_2018_build_37 (or
older) VST3 SDK or JUCE version 5.3.2. You should put the VST2 SDK in your
header search paths.
For new plug-in projects where you will be releasing both a VST2 and VST3
version, and you want the VST3 plug-in to replace the VST2 plug-in in
hosts that support it, then you should enable the JUCE_VST3_CAN_REPLACE_VST2
option.
Quick question : do we need to add the path of the VST2 SDK in the header section in every single JUCE project ? Since there is a global path for the VST3 SDK, we shouldn’t need to do this right ?
If you’re using JUCE’s VST3 SDK then JUCE projects will automatically have the path to the embedded VST3 SDK added to the compiler header search paths. So, in this case, you can either modify your copy of JUCE and place a VST2 SDK inside the embedded VST3 SDK, or you can add the path to an external VST2 SDK to the exporters in your project.
If you’re using a global path to a VST3 SDK, or if you have explicitly set a path to a VST3 SDK in an exporter, then JUCE projects will automatically have the path to the specified external VST3 SDK added to the compiler header search paths. If this external VST3 SDK also contains a VST2 SDK then the VST2 SDK will be detected automatically too.
I have just done the test on my Windows machine, and it doesn’t work.
I have a plug-in I want to compile in VST2 and VST3. I don’t want to add any extra header definition in the Projucer file.
So I have set the VST_SDK path in the global paths, the one called “Custom VST3 Path” which contains the VST2_SDK folder and the VST3_SDK folder. I save my project, I try to compile it, the VST2 and the VST3 format can’t be compiled at all.
If instead I set that global path to VST_SDK/VST3_SDK, the VST3 can be compiled, and the VST2 can’t
If instead I set that global path to VST_SDK/VST2_SDK, the VST2 can be compiled, and the VST3 can’t
So if I understand properly, right now with the last version of JUCE in develop and the last Projucer, there are a lof of problems. I don’t understand why someone would want to override the VST3 SDK which is in JUCE, and use its own instead (the JUCE team should update the VST3 SDK in the repo at every update anyway). And by doing so, with the current implementation, it is impossible to have both the VST2 and the VST3 SDK working using the global paths. And even if it worked, that would mean that we can’t use both the last version of the VST3 SDK in the JUCE repo AND the VST2 SDK ? Unless we start to create hacked JUCE repo or add the VST2 SDK header in every single plug-in project, or download the last version of the VST3 SDK, and put the VST2_SDK inside every single time ?
So in my humble opinion, it would be more convenient to remove the possibility to use a custom VST3 SDK, so all the people using JUCE is using the one in the repo, updated as often as necessary, and the global path will be updated to take into account the VST2 SDK only. So I can just set it once, and continue to use the VST2 SDK and the VST3 SDK which is now in the JUCE repo for a reason, without the need to copy and paste stuff in my JUCE projects definition.
Some JUCE users have patched their SDK, so not providing this functionality is not an option.
I obviously wasn’t clear enough in my previous post, so I’ll have another go at explaining. If you set a path to a VST3 SDK then something like $(HOME)/SDKs/VST3_SDK will be automatically added to your compiler’s header search paths, so you can use this knowledge to make it so that the compiler can also find the files it needs from the VST2 SDK by copying the contents of the VST2 SDK into the VST3 SDK.
