i’ve tested this on intel and arm64 but only on macos 12. i know for a fact this worked in april of this year but then i was on macos 11 and an intel mac. (edit: j/k, i didn’t have midi out enabled then, i can’t verify if this ever worked). also, the exact same setup works fine as an auv3 on ios.
to reproduce:
make sure juce is on develop and projucer is built from it.
open/export the AUv3SynthPlugin example
make sure plugin AU main type is set to kAudioUnit_MusicDevice
make sure plugin AU is sandbox safe is enabled
make sure Use App Sandbox is enabled
make sure there’s a valid value in Development Team ID
make sure plugin is a synth and plugin midi input are checked.
now build everything and open the standalone executable once. after this, you should be able to successfully run auvaltool (replacing the last two values with whatever projucer filled them in with):
$ auvaltool -v aumu Noyv Manu
...
Test MIDI
PASS
* * PASS
--------------------------------------------------
AU VALIDATION SUCCEEDED.
--------------------------------------------------
great. now go back to projucer and check plugin midi output. save, re-export, rebuild, and try auvaltool again:
$ auvaltool -v aumu Noyv Manu
...
Test MIDI
ERROR: -66745 IN CALL AudioUnitRender
* * FAIL
--------------------------------------------------
AU VALIDATION FAILED: CORRECT THE ERRORS ABOVE.
--------------------------------------------------
i couldn’t debug with auvaltool on arm64 but i managed to get a stack trace on an intel mac:
i found this ios bug which seems identical to what i’m seeing, although this would imply that apple’s not doing setup correctly in auvaltool which seems unlikely (or maybe they ported this feature from ios):
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 MusicDevice), then validation succeeds on Monterey again.
At the moment, I’m inclined to think this is a bug in auval. To check this hypothesis, I tested a non-JUCE-based plugin, specifically the “IPlugInstrument” plugin from the iPlug2 project. This plugin is also a MusicDevice with a MIDI in and out. When built as an AUv3, it fails auval in exactly the same way as the JUCE plugin:
Test MIDI
ERROR: -66745 IN CALL AudioUnitRender
* * FAIL
--------------------------------------------------
AU VALIDATION FAILED: CORRECT THE ERRORS ABOVE.
--------------------------------------------------
It looks like the MIDI output block is faulty in some way and causes the plugin process to crash during the call, causing auval to timeout.
I’ll create a feedback assistant ticket for this issue tomorrow.
thanks @reuk - i agree it seems like a bug in auvaltool and/or some internal apple framework, especially since the exact same thing happened on ios a few months back.
while we wait to hear from apple - is there a simple way to disable midi out only for the macos exporter but not for the ios exporter? right now i’m maintaining a separate branch for this. i tried setting JucePlugin_ProducesMidiOutput=0 in Extra Preprocessor Definitions but that seems to get clobbered by thte global project settings.
If your project uses an AppConfig.h header (by enabling “Use Global AppConfig header” in Projucer), you can add some code to the user code section (marked by // [BEGIN_USER_CODE_SECTION] and // [END_USER_CODE_SECTION]) to define JucePlugin_ProducesMidiOutput when desired.
what does that mean for my customers? if i build with xcode 13 will it work everywhere or does the xcode beta also update some core library which contains the fix?
I assume that the change is to auval itself, so unfortunately I think that users/customers will have to be running Ventura rather than Moneterey to benefit from this change.
