juce_AUv3_Wrapper.mm - auvaltool failure and work-around

[peteatjuce]

Hi folks,

I’ve found a weird one, where auvaltool was failing on macOS for my MIDI-generating plug-in.

My solution was to edit this file:

juce_AUv3_Wrapper.mm

Modify the loop:

if (auto midiOut = midiOutputEventBlock) {
                  for (const auto metadata : midiMessages) {

To protect it with:

              signal_catch_init();
              signal_try(label) {
                    // Put the above code in here
              } signal_catch(label) {
              }
              signal_end(label);

See: https://github.com/dhatbj/SignalRecovery

Not very handsome, but it does get me out of my immediate problem.

Pete

[reuk]

This sounds like a previously-discussed bug in auval on monterey:

Br: auv3 + midi out doesn't pass auvaltool on macos 12

I’ve investigated this a bit now, testing on Catalina (Intel) and Monterey (Arm). When the plugin’s main type is MusicDevice, then validation succeeds on Catalina but fails on Monterey. When the plugin’s main type is MidiEffect, then the validation succeeds on both platforms. Finally, if I modify the AUv3 wrapper so that it never calls MIDIOutputEventBlock or tries to send MIDI, but keep everything else the same (i.e. it still declares that it wants MIDI in and out, and has a type of MusicDev…

I’ve let Apple know about the issue, but haven’t heard anything back yet.

[peteatjuce]

Many thanks @reuk!

Just to note - my workaround definitely works, and I’d suggest you think about patching JUCE with it even if only for a while to provide a work-around for others.

Pete

[reuk]

I’m glad that it works for you, but I’m not sure whether this should go into the main JUCE distribution. If the program accesses out-of-bounds memory and segfaults in this way, then the behaviour of the program is undefined. It’s probably better to terminate the program immediately in this case.