VST SDK

1

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
2

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.

3

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.

4

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.

5

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:

6

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.

7

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?

8

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.

9

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

10

Just for the record, I’m trying to upgrade another project and it’s just a nightmare of VST errors all over again. And none of your wise words here seem to help.

My favourite thing is that the projucer has done this (-Ic:/SDKs/VST_SDK/VST3_SDK) on the Mac build server…

Where the hell is that coming from? It’s a Windows path. JUCE 5.4.4

c:\Users\jim\code\duck-pump>find /i "vst3" duck.jucer

---------- DUCK.JUCER
              cppLanguageStandard="latest" buildVST="1" buildVST3="1" buildAU="1"
              pluginFormats="buildVST,buildVST3,buildAU,buildAAX,buildStandalone"
                       vst3BinaryLocation="$(SRCROOT)/../../Builds/MacPlugins" stripLocalSymbols="0"/>
11

Well that’s super-strange. I don’t know if ti’s a weird bug,but the default paths on the build server (which I’ve never run projucer UI on turned out to be Windows paths!).

Also - the Projucer.settings file for SYSTEM user in Windows which jenkins uses when building ALSO has this default path in the globals settings. And I can guarantee I’ve never configured these settings because I’d have to look up the instructions on how to run projucer as system interactively!

So! Feature request: Projucer, Project Settings, Ignore All Global Configuration Yes/No (Default).

This would stop a project from using ANY global settings, thus guaranteeing that you can check our shit out of git and build it and get a consistent result.

2 Likes
12

Ok, this is driving me nuts. The config has reappeared in my system account, breaking my VST3 builds again:

<PROJECT_DEFAULT_SETTINGS vst3Path="c:\SDKs\VST_SDK\VST3_SDK" aaxPath="c:\SDKs\AAX" rtasPath="c:\SDKs\PT_90_SDK"/>

I deleted that two days ago!!!

I’ve deleted it again and made the config file read-only.

But it still won’t build.

C:\Program Files (x86)\Jenkins\workspace\Duck\juce\modules\juce_audio_processors\format_types\juce_VST3Headers.h(110,11): fatal error C1083: Cannot open include file: ‘pluginterfaces/vst/vsttypes.h’: No such file or directory [C:\Program Files (x86)\Jenkins\workspace\Duck\Builds\VisualStudio2019\Duck_VST3.vcxproj]

Even though it builds under my user account on the same system, it won’t build under Jenkins any more.

It’s like I’ve entered some new level of hell.

13

Right, I’ve got this problem Cannot open include file: ‘pluginterfaces/vst/vsttypes.h’ again.

<XCODE_MAC targetFolder="Builds/MacOSX" aaxFolder="./aaxsdk" vstLegacyFolder="./vstsdk2.4">

Is the Mac build config.

It’s a JUCE 5.4.5 build.

I had set the Projucer.settings file to be ‘read-only’. But something (Projucer presumably) seems to have REVERSED that, and inserted a new fucking instance of the fucking default VST3 SDK path

<PROJECT_DEFAULT_SETTINGS vst3Path="~/SDKs/VST_SDK/VST3_SDK" aaxPath="~/SDKs/AAX" rtasPath="~/SDKs/PT_90_SDK"/>

How do I stop this madness!?

Thanks!

:slight_smile:
:angry:

1 Like
14

So I think we can safely say that Projucer completely ignores the ‘read-only’ flag on MacOS.

Also one of the build jobs has just shrunk the Projucer.settings file by 10k!?

marmaduke:Pitchmonster OSX jenkins$ ls -l ~/Library/Application\ Support/Projucer/Projucer.settings
-rw-r--r--  1 jenkins  staff  14660  2 Dec 11:11 /Users/jenkins/Library/Application Support/Projucer/Projucer.settings
marmaduke:Pitchmonster OSX jenkins$ chmod -r ~/Library/Application\ Support/Projucer/Projucer.settings

marmaduke:Pitchmonster OSX jenkins$ ls -l ~/Library/Application\ Support/Projucer/Projucer.settings
-rw-r--r--  1 jenkins  staff  1662  2 Dec 14:02 /Users/jenkins/Library/Application Support/Projucer/Projucer.settings
15

And the new smaller file doesn’t include the VST3 SDK setting. So presumably later projucer runs and then reinserts the failing default for VST3 SDK causing all my builds to break!

The only projects running on this build machine should be using JUCE 5.4.3 or later.

So any bright ideas about the cause would be useful.

Also - a feature to disable global settings completely would of course probably fix it properly…

And perhaps it’d be helpful if Projucer didn’t overwrite read-only files. Rather defeats the point of that particular OS feature:)

16

Since the FileOutputStream has no replace mode, the workaround often is to delete the file before writing it, so Projucer never knew, it was read-only, and since the directory was writable, there was no error raised. I always disliked the way how FileOutputStream is (not) handling appending/overwriting.

BTW, as a quick fix, making the folder read-only would probably stop Projucer from doing that, but I support the need to override the global settings. That is not a good design at the moment.

1 Like
17

That’s a good idea re: the folder. Thanks!