Midi FX issue - Logic Pro and Mac M1

Has anyone else experienced problems with midi fx plugins in logic pro running on M1?
My plugin failed to output anything and even crashed sometimes. I built the most basic midi fx plugin to make sure it wasn’t anything I did. It swaps the notes as expected on intel. But It seems not to output anything in logic pro running on M1.
I built it with the latest Juce, XCode, macOS and the binary contains both arm64 and universal.
Any ideas?

Was a real stupid question as the alias pointed to a VST3 location for my DAW. Its however interesting to notice that the flood of available information is masking that basic info.

Wrong message thread, @Echotapper ?

I got a similar report from a customer on a MIDI FX plugin we distribute as a Universal Binary that I wasn’t able to test yet as I don’t have an M1 machine, so it seems like it’s a real issue.

1 Like

I’ve tried our midi plugin on M1 and it’s been fine, but it wasn’t in a universal binary and it wasn’t in logic. Will update when I get a chance.

1 Like

Bump, quite a critical bug. Unfortunately I can’t reproduce because I don’t have an M1 yet, but we have a few users reporting it.

I didn’t reproduce. But what we do know is that on M1s logic has a XPC service running plugins sandboxed.

So “isLogic()” fails. I see it also got some usage in the AU wrapper itself.
Did you try commenting those out resulting the logic workarounds to work even under the sandbox service?

My plugins aren’t writing any DAW-specific code so we’re not using isLogic() - maybe it’s the wrapper doing something different in that case?

:slight_smile:

1 Like

1: x86_64 only MIDIFX crashes AUHostingServiceXPC

I’m hitting the same problem. My MIDI FX plug-in works just fine when I start logic via

arch --x86_64 /Applications/Logic\ Pro\ X.app/Contents/MacOS/Logic\ Pro\ X

but crashes with the same popup as ops when I run it with:

arch --arm64 /Applications/Logic\ Pro\ X.app/Contents/MacOS/Logic\ Pro\ X

the crash occurs before createPluginFilter() is hit. The call stack appears to be garbage.

The plugin is non fat (slim), x86_64 only (because of a super annoying third party thing that we’re using that does not - and will not support M1).

The plugin also works fine when I uncheck “MIDI Effect Plugin” and check “Plugin is a Synth” - but that’s not what I want because I need the MIDI output (and the plugin doesn’t produce any sound).

So each of the following conditions have to be satisfied for the crash to occur:
1.) Logic needs to run natively on arm64
2.) Plug-In needs to be slim x86_64 binary
3.) Plug-In needs to be MIDI FX

2: arm64 MIDIFX Plug-Ins don’t appear to work either.

A further test also revealed odd behaviour: I made a completely new plugin from the Projucer template. When I make it a x86_64 binary the behaviour is as above. But when I make it an arm64 binary, then the UI doesn’t load:

image

hasty conclusion

My suspicion is, that this is an issue in AUHostingServiceXPC that doesn’t cope well with the MIDI FX plug-in type.

Versions:
JUCE 6.0.7
Logic 10.6.1
macOS 11.2.1

Any ideas for workarounds are highly appreciated!

2 Likes

Had a bit of time today with an M1 and reproduced the bug even in the most basic MIDI FX plugin:

1 Like

Bumping, hoping someone from the JUCE team can take at look at this very serious showstopper issue.

We’ll take a look at this when we’re able to (unfortunately we’re all remote and only one of us has an M1 machine so coordination is a bit difficult).

In the meantime, has anyone with an M1 Mac tried running non-JUCE MIDI FX plugins in Logic? As far as I can tell, the Kirnu Cream arp plugin is not written using JUCE. If this plugin fails to load on Logic/M1, that would suggest this isn’t a JUCE-specific issue.

So we’re having the same problem here, but with instruments that generate midi output, rather than specifically a MIDI FX.

@reuk I’ve just tried that arp plugin, and whilst it doesn’t crash, it also doesn’t appear to actually produce any output either. It only contains an x86 binary though, and does work fine when Logic is in Rosetta mode.

Again just to clarify. Logic in Rosetta Mode (or on Intel machines) don’t use any sandbox/ipc service. so it’s somewhere between Logic <> AUHostingServiceXPC (arrow or not).

I tried the Kirnu Cream Arp app that you linked on a M1 Mac Mini/Big Sur 11.2.1/Logic 10.6.1, it loads and runs, however I didn’t get events out of the plugin into the instrument on that track. But visually it seems fully functional and receives MIDI events.
Looking at ActivityMonitor it is running via AUHostingCompatibilityService which sounds like it is actually an intel binary.

I was building @eyalamirs plugin linked above, and it produces the spinner that you can see in PixelPackers post. If that is a crash, failed to start or indeed an endless loop I cannot tell from the outside. Didn’t find time to do the debug-SIP-sign dance…

1 Like

Thanks, it’s interesting that it loads successfully without causing a spinner. I’ll try to investigate this next week.

2 Likes

Findings so far:

  • Some MIDI messages were being sent without the proper alignment on ARM, which may have been causing issues for Logic when attempting to read them.
  • Adding a default audio bus (by supplying a BusesProperties instance to the base AudioProcessor's constructor) allows a MIDI FX plugin to load successfully in Logic. Without the audio bus, the plugin crashes when it is unloaded with what looks like a double-delete. It seems that the plugin may be quickly loaded + unloaded before it is ‘properly’ instantiated.
  • If I enable an audio bus in the MIDI Logger demo, I can load it as a MIDI FX plugin in Logic. If it’s the first plugin in the chain, it prints received MIDI messages, but subsequent plugins don’t receive any MIDI messages. If I add some basic logging, I see that the plugin is successfully calling the MIDI callback in the AU’s AUMIDIOutputCallbackStruct, so it looks like the messages go missing after they reach Logic.

A fix for the first issue has been merged:

Unfortunately this doesn’t fix the other two issues, so I’ll keep investigating.

8 Likes

I think I’ve found a fix for part of the issue I was seeing in the second bullet point above, where auval/logic were crashing (leaving a crash dump in Console.app) when loading a MIDI FX plugin. I was seeing this crash only when both the default bus layout was empty and isBusesLayoutSupported returned false. I have a fix for the crash, but unfortunately this doesn’t change the “spinner” behaviour in Logic, and MIDI FX plugins still need to use a non-empty default bus layout, or return true from isBusesLayoutSupported in order to load successfully. Fewer crashes definitely seems like an improvement though, so I’ll push that change once it’s been reviewed.

I’ve also managed to attach a debugger to the hosting process now, and I can say for certain that the plugin is calling the AU MIDI callback inside process block. This being the case, I’m reasonably sure that the lack of MIDI output is a Logic bug. The existence of an ARM AU with a functioning MIDI output would disprove this theory, but at the moment I’m not aware of any such plugin. (Please let me know if you are aware of any functioning ARM MIDI FX plugins!)

2 Likes

We tried few Midi FX plugins and they all seem to work fine under Rosetta. But when used with Arm they crash or fail to output anything. I looked it up in Logic Pro forum but didn’t really see anything about it, but I have submited a bug report, whatever good that does.

1 Like