The future of VST2 support in JUCE

Steinberg is promoting VST 3 and deprecating VST 2, and there’s been some unofficial discussion on the forum, but we wanted to let you know what that would mean for your active JUCE projects that use VST 2.

Here’s a summary of what we’re planning to change in JUCE, to give everyone a heads-up how it might affect your projects (spoiler: not very much!)

Step 1: add VST 3 and VST 2 headers to the develop branch (today)

We’ll push a new version of JUCE on the develop branch, in which:

  • We remove our implementation of the VST2 interface headers
  • We replace them with an embedded copy of the official Steinberg SDK files for VST 2 / VST 3

We believe that this solution will work better than the current situation using our headers. It means that as soon as you’ve pulled a copy of the JUCE repository, it will already contains everything you need to build VST plugins (both v2 and v3) with no other dependencies!

Step 2: push the VST 3 and VST 2 headers to master (27th June 2018)

Once we’ve tested the solution, we’ll push the change to the Master branch of the repository

Step 3: remove the VST 2 headers from the JUCE repo (October 2018)

Our embedded copy of the VST SDK will always be kept up-to-date to follow Steinberg’s changes, and in October we expect them to remove the VST2 sub-folder from it.

This will break “out-of-the-box” building of VST2 targets… However, if you’re a pre-existing VST2 licensee and have your own copy of those old VST2 SDK headers, the JUCE code that uses them will still keep working. It just means that you’ll need to tell your project where to find them so that it can carry on building as before.


Thanks for the detailed information !

Would it be possible then to include in the Projucer settings a new global entry for the VST2 headers location, like the current ones for VST3 and AAX formats ?

I don’t think it needs a separate path, given that the VST2 files live inside the VST3 folder. We’ll still provide the VST3 path, and you can carry on using that

Thanks for the update.
Many strange things are happening. GDPR, OpenGL’s deprecation, SDKs shifting around, I wonder what’s next…



Ok, so in October 2018, the VST3 SDK will be embedded in the JUCE base code.

But the projects will look for a separate location on the hard drive to find the VST2 headers if needed, and that will be the one called “VST3” in the global settings, where everything but the VST2 headers will be ignored, to stay up to date with the last version of VST3 SDK embedded in JUCE for the VST3 format only. Did I get it right ?

I still have a version of the VST2.4 SDK lying around so it confused me a bit

1 Like

Yes, that VST3 path has been in there for a long time, and there’s no reason for us to change it. I don’t think there’d be any point in adding another path specifically for VST2.

1 Like

By the way, another question for you @jules : you said that this is the old good original VST2.4 SDK which is currently embedded with JUCE. That means that very soon, you are going to replace it with the “VST3 to VST2 wrapper” right ? I have no experience at all with the VST3 wrapper for VST2, but I saw recently a few topics on KVR related with automation issues for the wrapper. And since that wrapper is going to be updated only for the next months, I hope all the issues related with it have been already solved, otherwise that means VST2 support in JUCE is doomed with the current scenario !

No… We’re not going to change anything. If you look inside a VST3 SDK folder, you’ll find that the old VST2 headers are inside - as long as you still have those files, the JUCE VST2 code will still work like it always did.

1 Like

OK it wasn’t clear to me, now it is, thanks for your answers, I’m reassured :wink:

The change discussed in the post is now on develop with commit cf4f12a.


Thanks guys, I’ll try the changes soon.

However, I think having VST2 now called “VST (legacy)” in the Projucer might not be the best choice, since Ableton Live 10 on Windows is today only compatible with that “legacy” format :innocent:

This is a good step forward! I take it this means users will no longer be required to download, install, and set paths for any plugin SDKs except AAX?

When I’m trying to teach new users about plugin development with JUCE (such as when I was assisting with a live workshop at University) setting up the VST SDK + Projucer paths always threw a wrench in things.

Interesting update and I’d love to be targeting VST3 as standard, but the lack of support for dynamic parameters is blocking me for now (see updateHostDisplay() VST3). Do you think that’s something that might be looked at between now and October? Any insights into how well supported the kParamValuesChanged call is in DAWs?

Having said all of that, I guess I’m probably going to need to support VST2 for as long as Ableton doesn’t make the move to support VST3.

It’s a pain supporting multiple formats. Perhaps it’s time to “deprecate” Ableton Live :wink:

1 Like

VST2 is fully functional simple format being removed due to bureaucratic decision.
I think it would be a good time for RTAS removal deadline.

  • RTAS unlike VST is only 32-bit
  • RTAS requires compiled library that’s becoming trickier and trickier to build under Mac each release.
  • RTAS unlike VST isn’t maintained by any active host as an exclusive format (versus VST/Ableton).
  • It’s worth JUCE devs would put their resources on adding newer useful formats and extensions than maintaining 32-bit deprecated format.

Just seen this post. Could VST errors after latest pull be related? thx

It is going to get even more tricky to build RTAS soon, see this note on building 32-bit targets in XCode 10 (public reference), I don’t suppose discussing this in any great detail is allowed during the beta as it’s under NDA.

They have made some public statements about the future of 32-bit apps…


If you guys want to talk about RTAS that’s fine, but please don’t hijack this VST thread!

Is this compatible with Steinberg license? Providing the VST2 headers is currently the subject of DMCA takedown notices on github (yes, they provided a list of all repos on github that provided the headers and they CANNOT stay there…)

1 Like