Issues with M1

Audio Plugins
1

Hi, just setup a new M1 machine and have a couple of problems:

  1. AU plugins are only being recognised from the main Library folder in Logic and in AudioPluginHost. Anything in ~/Library is not being picked up - don’t remember this being a setting anywhere, but maybe it is? FYI, if I manually copy the JUCE generated plugin in ~/Library to /Library it is picked up fine.

  2. Live will only show release build plugins and not debug build plugins - I know Live isn’t officially supported on Big Sur yet, but this seems a strange thing to happen - wonder if anyone has any thoughts?

Thanks

2

Did you try the killall -9 AudioComponentRegistrar from the terminal.
(this was ‘introduced’ by Apple for a while now :slight_smile: )

Live will only show release build plugins and not debug build plugins

Didn’t notice such thing.

3

thx - i’ll give that command a go.

so you’re saying that your debug built plugins show up in Live ok?

4

You didn’t elaborate if it’s AU/VST3 etc.
But the AudioComponentRegistrar has been flaky since 10.11 iirc.

1 Like
5

The plugins not showing up in Live are VST, VST3 - they only show up in release build, not debug build. I presume the AudioComponentRegistrar only affects AU so might be the Logic issue, but won’t be the Live issue.

6

Are you building UBs? (haha, some confuse it with undefined-behavior, but back in the days it was also Universal Binaries… here we go again).

Xcode would default to building the arm (…Apple Silicon) only debug instead of the Rosetta friendly one.

2 Likes
7

Hi, I have

image
image784×206 12.6 KB

But that is not different between debug and release build so wouldn’t think that would be responsible.

I tried the killall command the plugin has appeared in Logic (thx), but am now getting this:

image

8

Also check the “macOS Architecture” of your Debug configuration. Just a guess, but maybe Live is x86_64 and your plugin is only build for arm because that’s the active architecture. It of course makes sense to not build the universal binary for all the architectures during development - but my uneducated guess is, that rosetta 2 only translates x86 to arm - not the other way around.

image

If you want to check which architectures are inside a binary, you can run the “file” command on the binary inside the bundle:

file MyPlugin.vst/Contest/MacOS/MyPlugin

or on Live:

$ file /Applications/Ableton\ Live\ 10\ Suite.app/Contents/MacOS/Live
/Applications/Ableton Live 10 Suite.app/Contents/MacOS/Live: Mach-O 64-bit executable x86_64
3 Likes
9

thanks - that was it - changed debug to build “standard 64-bit” and it built the x86_64 version also.

1 Like
10

image

I can’t find anything on the net about this error at all - anyone come across this?
The AU loads fine into Live - I’ve never seen this message in a couple of years of running the plugins on intel. thx

11

What JUCE are you using is this latest develop branch?

1 Like
12

juce 6. develop branch.

13

Spent alot of time on this to no avail unfortunately.

Can’t put a debugger on anything running in Logic on the M1 - createPluginFilter() never gets called before the unstable dialog is presented. Makes me think it’s not actually related to anything I’m doing and something else.

14

So you were trying to debug an Intel version instead of native ARM64, Which would never hit breakpoints since it’s bridged?

15

I don’t think so - I’m building the stuff on an M1 machine so I should be running native plugins under Logic…

16

Argh, you’re right (with Logic at least).
Apparently Logic Pro X on M1 (I’ll test on Intel), is now sandboxing plug-ins…

image
image1676×168 24.7 KB

I’m still figuring how to attach to AUHostingService which is where you plug-in is actually running…

REAPER for example, does run AUs not sandboxed so this isn’t enforced by the AU API.

1 Like
17

On Arm/Big Sur in Logic / Garagebands auv2s are out-of-process. There is an XPC AUHostingService helper, which i have been trying to debug, but can’t get it to hit breakpoints

18

snap

19

so I’m guessing this new dialog might be due to some problem in this hosting process… and why it’s not got any info on the net
I know that I got rid of 1 error by changing a timeout on a wait event from 1000ms to 50ms

I wonder if there’s any way to force the plugins to load in-process?

20

I figured out how to re-code sign AUHostingServiceXPC*, which reside on the read only system partition. I think this was necessary, but it might have just been turning off SIP that solved it. Now I can attach to AUHostingServiceXPC_arrow and hit breakpoints. DM me for info if you want to do that. I am on a DTK, so I am not too worried about bricking my system.

3 Likes