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)
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.
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.
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?
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.
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.
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.
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 ?