This stuff is driving me bonkers. I’ve got a project from someone else and I’ve spent 30 minutes already trying to deal with VST SDK errors. It’s a new kind of hell.

  • vsttype.h missing
  • Global paths overwriting project specific paths
  • Bundled VST SDK (is there one?) not having vst2.x/vstfxstore.h even though I’m trying to build a VST3.
  • Wrong version of VST3 SDK

Still working on it…

Projucer could up its game here somehow! edit: or we could have a web page with definitive instructions, links and a table of what version of what goes where for which JUCE version!

1 Like

You need the VST2 SDK if you’re building a VST3 to seamlessly replace an already-existing VST2 plug-in. The option for controlling that is JUCE_VST3_CAN_REPLACE_VST2 in the juce_audio_plugin_client module.

If you are not using a modified version of the VST3 SDK, just use the one that’s bundled with JUCE. Make sure any paths to a custom VST3 SDK are empty. We’re going to get rid of this option in the Projucer soon - anyone who’s using a modified SDK will be able to work out how to do it outside of the Projucer config.

Tom - the problem could be solved by a document describing what the hell to do.

We’ve got every version of JUCE from 4.x to current for different projects and it’s a real nightmare of guesswork and searching to find any instructions! I don’t know if getting rid of the custom SDK option out of the JUCER is going to make it any easier.

We will need to be building VST2s eventually, but for testing this one I just needed V3 to build. But you are saying we need to install a VST2 compatible SDK. What version of the bloody thing do I need where :slight_smile: Another project we have has VST3 installed by didn’t need a VST2SD separately to build ok…

I’m completely lost!

I realise this is half the fault of Steinberg.

If you want the VST3 to replace the VST2 in hosts (rather than appear alongside it) then you will need a VST2 SDK. This isn’t available to download anywhere anymore, but if you have one of your own then it’s almost certainly the latest version and it will be compatible.

If you don’t need this replacement of an existing plug-in, then you don’t need a VST2 SDK.

JUCE_VST3_CAN_REPLACE_VST2 defaults to false for new projects, so I’m not sure how you’ve ended up with it enabled without consciously opting in.

If you’re not patching the VST3 SDK then simply use the one that comes with JUCE - there won’t be any versioning issues as there’s no way to get out of sync. The only way you can get into trouble here is if you are using your own version of the VST3 SDK and, hopefully, removing the option from the Projucer will mean that people won’t end up doing that accidentally.

Probably because we have a template project we use for new plugins which has it enabled, though I didn’t know about it :slight_smile:

So we should put the latest VST2 sdk into the project, and not specifiy a VST3 SDK and everything will be fine? Previously we’ve had to inject a specific VST`3 sdk but I don’t remember why :slight_smile:

We have had an embedded version of the VST3 SDK since June 2018, so for any JUCE-based project younger than that using the embedded VST3 SDK is the way to go.

Ok - so maybe we are in a hole with this because of the backwards VST2 sdk compatibility requirements and possibly we had a VST3 SDK version that included a VST2 SDK ?

Also do the global paths override the project-specific SDK paths?

Things are little confusing if the VST3 SDK you were using had the VST2 SDK copied inside it - then you can have empty paths to the VST2 SDK but you’ll still be able to find the required VST2 files as they’ll be included in the VST3 search paths. Older versions of the VST3 SDK had a script in it that encouraged users to copy the VST2 into the VST3 SDK.

The project specific paths override the global paths.

Cheers tom! Will try and remember all this for next time :slight_smile: