So it seems that an arm executable cannot host plugins of a different architecture:
Update Plug-Ins to Universal Binaries
A universal plug-in runs natively on any Mac computer. If your app supports a plug-in model, create universal versions of the plug-ins that you manage. If your company allows external developers to contribute plug-ins, encourage those developers to create universal versions of their plug-ins.
Universal plug-ins are essential if your app loads those plug-ins directly into its process space. Code running in the same process must support the same architecture. If your app attempts to load a plug-in with an incompatible architecture, the system reports an error at load time.
This is not quite true as from testing here you can load Intel AUs into an Arm executable, VST2 and VST3 throw up problems though as the correct architecture cannot be found.
You can see this by doing a build of AudioPluginHost on a M1 machine and running it as Rosseta, scan your plugins and instantiate some, all is fine.
Now Run the Arm version, AUs will load but VSTs will not.
Apples advice here seems to be to host the plugins in an XPC server or the same architecture and communicate with that.
Has any thought been put into all this yet by the June team?
I wonder if Logic/Garageband/Mainstage/FCP have some calls into Rosetta to convert the AUs?!
I guess the developers of LPX etc would have pointed out early on, that if they could not load Intel plugins - they’d have zero 3rd party plugins to show on launch day - so perhaps given an api to invoke Rosetta on AU plugins?!
also… Ive noticed my universal binaries will not load on Mojave, I guess its not aware of them… I wonder if this could change going forward? (perhaps a patch to Mojave/Calalina) …
or do we somehow just strip the universal binary for older versions of macOS?
Rosetta is a translator, my understanding is… when the intel binary is first attempted to be loaded, it translates this to arm code, then it can run this arm code as ‘native’ (it caches this translation so it does this only once) - so no xpc process would be required (not to say they dont run it in one, sandboxing of plugins is common these days anyway)
surely, this is why the AudioPluginHost can load the AU without any extra code… since once converted its just using the arm version of the AU Rosetta built.
this is also why it cannot load an Intel VST2/VST3… since Logic etc will not translate VST2/3 into arm, so nothing for AudioPluginHost to run.
that said, yeah, I dont know if its Logic (etc) calling Rosetta to get the plugin converted, or if Rosetta just has a ‘special case’ for AUs - I could see either as valid approach for Apple.
I guess the way to test that is … put an Intel AU on the M1, and try to load it directly in AudioPluginHost (native builld) without running Logic etc beforehand …
if its shows up, then indeed Rosetta has a special case built-in for AUs,
if it doesn’t, and only shows up after Logic (etc) is loaded, then its partly in the DAW.
anyway, I cannot say, Ive looked into this in any real depth… the search I did of apple docs were pretty ‘vague’ about how it works - but Im sure there must be some more details docs somewhere.
Its a pity they are not going to ‘backport’ the loading of universal binaries to Mojave, I know quite a few users who did not move to Catalina due to various compatibility issues… but not entirely surprising, Apple do like to push their community ‘forward’
(guess it means, I need to update one of my macs to Catalina to test this side of it)
I’ve built a universal binary plug-in (arm64, x86_64) and it loads without issues in REAPER on macOS 10.10. This makes me believe that such universal binaries are backwards compatible after all.
yeah, Id assumed universal binaries would work… given the basic concept has been there since the intel/powerpc days… and was still being used for 32/64bit transition.
but as I said, I tried my plugin (vst3) as a Universal Binary on:
Ableton Live 11 Beta (so Intel) on Big Sur - and it worked
Ableton Live 11 Beta on Mojave - and it failed to ‘find’ the plugin
However, I have some doubts… that something else odd is going on.
I’ve noted on a different forum post here, that my VST2 is not loading into Ableton Live 11 Beta on BigSur, however the VST3 loads fine…
But the VST2 (and VST3) loads correct in the AudioPluginHost.
Similarly, when I build the VST2 (and VST3) on Intel, it loads fine.
so, I’m not 100% sure that the build is exactly ‘correct’, and Im using CMake with Juce, so perhaps this has something ‘not quite right’.
perhaps I could try an older version of my build that was built around projucer using xcode and see if that has the same issues.
in fairness, none of this is an issue for me… Im only using the mac as a development platform - Im not releasing plugins on it. so as long as one format works on my Mac Mini M1, Im good to go
I compiled our plugins for arm64/x86_64 universal binaries using JUCE 6.0.4. I also veryfied with the lipo command that the binaries indeed contain slices for both architectures.
I compiled an arm64 pluginval version. It loads and validates our plugins just fine. The arm64 pluginval loads the arm64 version of a plugin, x86_64 pluginval loads the x86_64 version (in both cases I loaded the same fat binary file).
I downloaded the recent beta of Reaper. it runs as an arm64 executable. Our VST3 and VST2 plugins fail to scan, but I can’t see why (no log files, no stdout)
I downloaded the recent beta of Tracktion Waveform. Our VST3 and VST2 plugins fail to scan. The logs say: - No plugins found in <somePath>.vst3
I compiled AudioPluginHost from JUCE 6.0.4. Scanning the plugins when running as arm64 triggers an assertion in juce_VST3PluginFormat.cpp:863 - “The plugin needs to provide a factory to be able to be called a VST3. Most likely you are trying to load a 32-bit VST3 from a 64-bit host or vide versa” Scanning when running via Rosetta 2 loads the x86_64 version of the plugins
id already used ‘file’ to check this, so knew it was a unversal binary.
anyway, it wouldn’t have load in Ableton Live if it didnt contain the Intel binary
I think there is something else going on, possibly to do with cmake builds, really I need to get some feedback from others that having been building vst2 and vst3 with cmake/juce on the m1.
