JUCE CMake produces "invalid" VST (effect/synth unknown) in FL Studio

Development
1

I’ve updated my JUCE Audio Plugin’s build system to use CMake:

FL Studio considers the VST and VST3 to be invalid, and cannot determine whether it’s an effect or a synth:

image
image1508×140 51.8 KB

The FL Studio logs don’t include any more detail:

[30-12-2021 23:37:28]     Verify plugins
[30-12-2021 23:37:28]     Scanning... [VST3] /Library/Audio/Plug-Ins/VST3/juicysfplugin.vst3
[30-12-2021 23:37:28]     Verify plugin - /Library/Audio/Plug-Ins/VST3/juicysfplugin.vst3
[30-12-2021 23:37:28]     [verified] "juicysfplugin" error
[30-12-2021 23:37:28]     Failed to load plugin (!plugin.IsValid)
[30-12-2021 23:37:31]     Scanning... [VST] /Library/Audio/Plug-Ins/VST/juicysfplugin.vst
[30-12-2021 23:37:31]     Verify plugin - /Library/Audio/Plug-Ins/VST/juicysfplugin.vst
[30-12-2021 23:37:31]     [verified] "juicysfplugin" error
[30-12-2021 23:37:31]     Failed to load plugin (!plugin.IsValid)

The VST3 works fine in JUCE’s Audio plugin host:

image
image1614×1260 104 KB

I can even make it work in FL Studio, but only by manually configuring in FL Studio that the plugin should be regarded as a synth:

image
image2122×620 132 KB

image

image

image
image1514×186 55.5 KB

This manual override was never necessary under my original Projucer build system.
Could it mean that JUCE is not setting the VST categories correctly?

I’m passing the following arguments to juce_add_plugin:

IS_SYNTH TRUE
IS_MIDI_EFFECT FALSE
VST2_CATEGORY kPlugCategSynth
VST3_CATEGORIES Instrument
AU_MAIN_TYPE kAudioUnitType_MusicDevice

I thought this would be sufficient (these categories match the ones in the AppInfo.h which was generated under my original Projucer build system).

Moreover, I get exactly the same problem if I build JUCE’s example Audio Plugin:

cd ~/git/JUCE/examples/CMake/AudioPlugin
# set CMAKE_PREFIX_PATH to the location where I installed JUCE
cmake -B build -DCMAKE_PREFIX_PATH="$HOME/juicydeps"
cmake --build build

Any ideas about what the problem might be, or anything I can run upon the audio plugin to check that the categories are set correctly?

I’ve uploaded a distribution for M1 Mac here:
https://birchlabs.co.uk/share/Plug-Ins.zip

2

I don’t have an M1 mac with FL installed, but I tried this out with the Audio Plugin Example (but with IS_SYNTH TRUE) on an Intel mac, and FL was able to scan it and categorise it correctly. I did notice that it couldn’t work out the categorisation the very first time it scanned the plugin, but it was able to on every subsequent attempt. I think there’s a chance I had the ‘verify plugins’ option off the first time, so maybe this is required in order for FL to detect the category.

3

@reuk wow, I think you’re onto something!

I think IS_SYNTH isn’t the important part (in fact, I believe this particular plugin is an Effect, so IS_SYNTH FALSE may be more appropriate anyway).

On my M1 Mac, I tried building that Audio Plugin Example for Intel (without changing the IS_SYNTH setting): -DCMAKE_OSX_ARCHITECTURES=x86_64.

I asked FL Studio to scan for plugins, and the Intel plugin passed verification! FL Studio can run Intel plugins via a bridge, so I was able to run this without putting the IDE itself into Rosetta mode.

Likewise, I was able to build it as a Universal Binary, à la '-DCMAKE_OSX_ARCHITECTURES=x86_64;arm64' — and this satisfied FL Studio’s verification too!

I managed just now to build my own plugin as a Universal Binary (very fiddly since it has dependencies it needs to statically link to… so need to control where it sources the arm64 and x86_64 objects), and it passes verifcation.

But generally it still feels like “arm64-only plugins ought to be supported”. Do you know whether it’s likely that “FL Studio is verifying the plugin incorrectly”, or is it “JUCE is not writing metadata into the right places when you do an arm64-only build”?

4

I’ve not tested this in FL yet, but this sounds like a bug that exists in Ableton Live 11.1 beta (the M1 native version) as well: They only allow universal binaries but not ARM-only binaries to be loaded.

Hopefully in both cases this would get fixed: might be worth it to report that issue to Image Line.

5

I reported this issue to Image-Line just before I created this thread on the JUCE Forum.

But because I raised it via the Help dialogue: the topic has ended up becoming private on their Forums (since it includes diagnostics from my system):
https://forum.image-line.com/viewtopic.php?f=1965&t=270997&p=1689306

No replies yet, but it’s not overlapped with working hours very much.