Is there a list with all compilerflags?
In my case I have a plugin and there is an AU and a VST3 version. But as not all features are supported by both formats I have at some parts different code for the different formats and want to just compile it for the specific plugintype.
I tried JucePlugin_Build_VST3 but these seems not to work, it still compiles it for the AU as well.
It used to be possible to name your own source files *_AU.cpp or *_VST3.cpp and Projucer would only compile them as part of the specific plugin type target. It seems that this feature was deemed a bug and was removed in:
I don’t know what the current way would be though…
@reuk any pointers?
Hmm this probably wouldn’t be the best solution for my case anyways, as I just have a few lines of code that differ
so something like
#if VST3
…
#elif AU
…
#endif
would be the kind of thing I look for.
There are compilingflags like JUCE_WINDOWS, JUCE_MAC, etc. so I was wondering if there are some for the Pluginformats as well.
All your shared plugin code that you write is built only once into a static library. As a second compile step, the wrappers for each format are built and link against this library. This means that there can’t be a define for the plugin format since that would require that the whole code is compiled multiple times for each format.
But you can query the public wrapperType member of your processor instance and put that logic into a simple runtime if statement in case that is a suitable option for you.
https://docs.juce.com/master/classAudioProcessor.html#a091b617d5bf926e54b510fb038917534
For what I do right know this solution works fine, thanks.
The previous implementation seemed to be a bit too greedy with the filenames that it selected to be built into the wrapper targets. There’s a bit more info in this thread: Bug? Filenames and underscores - #4 by reuk
It’s possible that the intended behaviour was to allow files with suffixes like Standalone and VST3 to only be built into the corresponding targets, but I don’t think this behaviour is documented, and the previous implementation looked like an accident, which is why it was removed.
If there’s a compelling use-case for this functionality, I’ll look at re-introducing it. In the meantime, I’d suggest using the runtime wrapperType technique that @PluginPenguin suggested instead.
For know I have only two situations where I have differences between different “plugin” versions. As they don’t have any notable influence on CPU usage the wrapper version works fine.
One thing would be that for DAWs that support it I use a Skin for my plugin that responds to the trackcolour, in my testing it seems that reading trackstats is not possible in AU, so this is why I made it exclusive to VST3 (and specific DAWs, as not all support it).
I was just wondering if there would be a way to do this with compiling flags just in case I would have a similar situation in the future with a feature that has more impact in CPU usage.
The other “feature” where I have differences is on iOS, here I add a keyboard-component to the standalone app, but not to the AUv3. But I guess this has to be done in runtime anyways, if I understood it right how AUv3 works.
At the moment, there isn’t. If there were some facility that allowed source files to be built on a per-wrapper basis, then you might be able to forward declare a function like Colour getSkinBackgroundColour (const MyAudioProcessor&) and implement this function separately in source files for the VST3 and AU formats. For the scenario you mentioned, such a solution would probably be more heavyweight than necessary.
