No flock.cpp in VST SDK?

For me I always left it as Compiler default, after a long struggle with C++11, that was affected, when I tried to use something else… especially when linking to the AAX library. Since then I never had any problem, I can support back to 10.7 easily by setting the deployment target (haven’t tried 10.6, but I think it is old enough to forget about it… that was the time point when there were architecture changes, so that was for me reason enough to not bother about <10.7)

For that topic have a look at: What's the earliest OS people are compiling for?

HTH

Ok! Thank you for that nugget of information, I’ll look into it!

Another issue with vst 3.6.8 has been solved with commit 57d7e98 on develop.

@ollierikkeskinen Hmmm, are you sure you are seeing those errors with the latest XCode and a deployment target of 10.10? I can’t seem to reproduce the errors you are seeing.

1 Like

I get identical errors with @ollierikkeskinen when trying to use develop or master tip, 5.1.1 is the latest version I’m able to get link VST3 correctly.

My OS X dev configuration is:

  • OS X Sierra
  • Xcode 8.3
  • 10.10 SDK
  • deployment target 10.7
  • VST SDK 3.6.7

I also tried VST SDK 3.6.8, 10.12 SDK and deployment target 10.10 and their different permutations (cleaning and re-exporting the project with Projucer between each attempt), but no luck.

I’m also struggling to reproduce those errors. Are you including any JUCE headers in an unconventional way?

It’d seem I found the breaking commit:

eda613c6db698f31ab2189cc289c9de2db821142
Moved all "namespace juce" declarations from module headers to individual .h and .cpp source files. This makes life a lot easier for Intellisense and other IDE autocompletion tools.

After this, the following function in juce_VST3_Wrapper.cpp starts to fire namespace errors:
JUCE_EXPORTED_FUNCTION IPluginFactory* PLUGIN_API GetPluginFactory()

The juce namespace scope ends before this function. When moving it to after the function, everything seems to compile neatly with latest tip as well. So that is hopefully the fix, could you check this? :slight_smile:

I’m pretty sure we don’t want that function in the JUCE namespace. Do VST3 plug-ins still load correctly with that change?!

Can you reproduce this issue with any of the JUCE example projects?

Hi Tom,

Thank you for looking into this!

I did further checking. VST3 plugins loaded correctly with the change of the namespace, but that probably is not the culprit here.

We have set the JUCE_VST3_CAN_REPLACE_VST2=0. When switching this to 1, VST3 compiles, when 0, it doesn’t. I was able to reproduce the issue with JuceDemoPlugin, with the XCode exporter.

The reason for using this flag is that without it, some hosts replace VST2 with VST3, and then mishandle the VST3 version. VST3 seems to be trickier to implement, and since VST2 is solid, this at least gives the customers a plugin that they can work with.

Thanks!
Olli

Probably not the correct way to address this, but by adding

#if ! DONT_SET_USING_JUCE_NAMESPACE
using namespace juce;
#endif

just before opening the juce namespace in juce_VST3_Wrapper.cpp I was able to get VST3 compile without errors with JUCE_VST3_CAN_REPLACE_VST2=0.

EDIT: tested with develop commit 202cad899124d576293d3d7a6fbdebc69379f5af

juce_VSTInterface.h seems to begin with

using namespace juce;

and that header is included only if JUCE_VST3_CAN_REPLACE_VST2 flag is set.

Yep. Restoring using namespace juce is the way to go here. I’ll push a fix to the develop branch shortly.

Did you try on Windows? I’m pretty sure that there the namespacing will change the signatures of the VST3 entry points. I suppose it’s a bit of a moot point now anyway.

Thanks so much, it’s been a hassle to find 3.6.7, which is the only way it seems to make the latest JUCE Plugin Host to compile

I really don’t know why this seems to be creating so much confusion, but please don’t make it worse by recommending that anyone gets 3.6.7!

The situation is very simple: The latest JUCE codebase (i.e. what you get from Github) works with the latest VST SDK (i.e. 3.6.8).

We don’t recommend using older VST SDKs or older JUCE versions.

AFAIK, because the function is extern “c” (JUCE_EXPORTED_FUNCTION) you don’t need to worry if it is inside the namespace or not from the linkers perspective. And there’s a good chance it was inside the namespace before. So I’d leave it in there.

JUCE_EXPORTED_FUNCTION is not the same as extern “C”. The two things are very different…

EDIT: nope, sorry, I take that back! They used to be very different, but apparently that’s no longer true!

You got me worried there for a moment :wink:

It’s possible that this issue is hitting those people who download JUCE from the zipped file here: Download - JUCE

To outsiders, it’s very likely that the zipped file feels like the “stable” release whereas anything on GitHub feels like “under development”

2 Likes

The situation isn’t that simple : my company buy Juce to release audio plugins, hence when we release a product we MUST provide the maintenance and the capability to ensure built stability and reproductibility. To achieve these goals, a product must depend upon well known released and tested software versions.

As is, the Juce master branch is used to fix bugs, hence development cycles occur on develop and on master.
There are no bugfix, feature or release branch to host for instance VST 3.6.8 integration.
If this was the case, this feature branch for VST 3.6.8 could have been created from Juce 5.2.0 and merged both in develop, a release branch to test the feature.

Upon succesfull testing on the release branch it could have been merged in master then tagged.

With the current versioning and development process used in Juce git, we need to rely on well tested tags.
In this situation, can you provide a date for the next Juce release, as we have an audio plugin that needs VST3.6.8 as some bugs are fixed within this version ?

Maybe I don’t quite understand the problem… AFAIK the 3.6.8 update has been available on the master branch since November?