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