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.
Hello @t0m !
I won’t, it’s going to be a pain to maintain
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.
I’m with @IvanC…this is overly complicated and it just isn’t working for me.
- I have a copy of the
plugininterfaces/from the VST2_SDK in my VST3_SDK folder.
- My Global Custom VST3 path is set correctly to my VST3_SDK folder.
My VST2 plugin is failing build here in juce_VST_Wrapper.cpp:
#include "pluginterfaces/vst2.x/aeffect.h" #include "pluginterfaces/vst2.x/aeffectx.h"
Can we just have a VST2_SDK folder setting?
What am I not understanding?
It looks like this might be related:
I agree, it would be the best option to have a new global path entry to set the VST2 path
I’ve added a global path setting for the VST2 SDK. You’ll need to re-build the Projucer after pulling this commit and it should be available.
Hello @ed95 ! Thanks, that’s perfect this way.
Last question : if I want to use the VST3 SDK inside the JUCE SDK, what I need to do is to replace the custom VST3 path entry with an empty path right ?
Yup, just leave that path empty and the embedded JUCE VST3 SDK will be used.
If you download from here https://www.steinberg.net/vst3sdk you will find the VST2 SDK is still contained within (was last time I checked a few days ago at least), BUT I think now the deadline has passed for getting a VST2 license to distribute, so you wouldn’t legally be allowed to do that.
Sorry, but I was mistaken about the VST2 SDK being in there. There are files that look like they are VST2 SDK, but the files that are needed aren’t in fact distributed any more. Basically, you’re SooL now if you want to support VST2 and didn’t get in before the deadline last year.
Gotta say, and I understand Steinberg needs to move things on, but removing official VST2 support before one of the major DAW providers had VST3 support was kinda dickish. Of course, maybe Steinberg had been telling them for a while this was going to happen and they ignored them, but it seems the only people losing out from this are the devs, not any of the major companies involved in these choices.
Yeah, and Ableton users who won’t be able to run any plugins by newer devs (unless via a VST -> AU wrapper).
I’m guessing that the plugins that come bundled with Live are of a format specific to them, and I wouldn’t be surprised if they open it up to 3rd parties in the near future, which would mean another format to support for us.
Surely it can’t be that difficult for Ableton to finally come up with the VST3 support pretty soon? The JUCE VST3 hosting code has about 3200 lines of code, so it seems it isn’t an absolutely huge problem to solve…(Of course ironing out all the bugs and corner cases can take time…)
It’s been 10 years since VST3 was released, 1 year and 3 major versions of Live later and still naught.
In the meantime maybe some of us could hack a vst3 to vst2 adapter using juce… or does the stuff we had to sign prohibit us from doing that?
I don’t think it’s disallowed but it would need to be done by a developer who has managed to get their VST2 license application accepted in time. But I don’t think it’s necessarily that a great idea, it would really be about patching a problem Ableton doesn’t apparently want to deal with.
It would need to be published by a dev with the agreement, no reason somebody without it couldn’t do it and have somebody else publish on their behalf.