We are experiencing that our standalone Apps are receiving SysEx messages sent from another App through a Virtual MIDI Port, but the same instrument as AUv3 plugin is not receiving any SysEx message.
Are MIDI SysEx messages forwarded to AUv3 plugins on iOS?
We have built a very simple dedicated AUv3 debug plugin to exclude any other implementation error in our code, and the result is identical.
Regular MIDI messages generated by the Standalone App reach the AUv3 plugin. SysEx MIDI messages don’t.
We made several tests, and we cannot get any SysEx message reach our test plugin, when it is loaded as AUv3 in any host, also with regular (non-virtual) MIDI Ports.
Camelot Pro has an embedded MIDI Monitor that logs the description of any MIDI message received. MIDI messages are then forwarded to any AUv3 plugin loaded on the Layer the MIDI Port is connected to.
Test with Camelot because it has an embedded MIDI Monitor, but the result is identical with any AUv3 host (e.g. GarageBand, AUM).
So, I see only two possibilities:
Plugins made with JUCE are not able to get SysEx messages (anyway, I had a look at the code, and JUCE APIs just deal with plain bytes, so it seems weird to me that they discard SysEx messages)
SysEx messages are somehow discarded or lost in the communication between an AUv3 host and an AUv3 plugin
After more than one year we still experience such issue, and it’s becoming problematic.
Why do SysEx messages get lost before reaching processBlock() method of the AudioProcessor?
As I understand it - and I hope to be corrected where I’m off-base: MIDI events (note on/off, controller) are typically routed, in modern DAW’s, to the channel assigned to the plugin.
However SYSEX events are “meta-events” which are not sent to specific channels, but rather on the “broadcast” MIDI channel, meaning there’s a chance your plugin is not going to receive meta-events unless its listening to all MIDI channels…
Can you easily set up your plugin to receive on All MIDI Channels, and re-try your SYSEX message test?
It appears the issue is specific to JUCE-based AUv3 plugins. While my standalone plugin can receive SysEx messages, the AUv3 version of the same plugin does not.
To investigate further, I tested two different MIDI monitor tools: one developed using JUCE and the other without JUCE.
AUv3 (tested with AUM): only the MIDI monitor developed without JUCE successfully receives SysEx messages
Standalone: both MIDI monitors successfully receive SysEx messages
This strongly suggests that the problem can be into JUCE modules
I’ve tested with MIDISpy (which appears to be made with JUCE) and mfxMonitor loaded into AUM.
I also created a test MIDI Monitor using JUCE, which simply logs all incoming MIDI events:
void TestPluginAudioProcessor::processBlock (juce::AudioBuffer<float>& buffer, juce::MidiBuffer& midiMessages)
{
juce::ScopedNoDenormals noDenormals;
auto totalNumInputChannels = getTotalNumInputChannels();
auto totalNumOutputChannels = getTotalNumOutputChannels();
for (auto i = totalNumInputChannels; i < totalNumOutputChannels; ++i)
buffer.clear (i, 0, buffer.getNumSamples());
for (const juce::MidiMessageMetadata metadata : midiMessages)
{
auto midiMessage = metadata.getMessage();
logs.add("- " + midiMessage.getDescription());
}
}
To be completely certain the issue originates from JUCE modules, I plan to build a native MIDI Monitor using Swift as soon as possible. I’ll also test MIDILogger when I get the chance.
Has anyone successfully received and logged SysEx messages in an AUv3 plugin built with JUCE?
Here’s a quick test video demonstrating the issue:
UPDATE:
I tested with MIDILogger and the result is the same: SysEx messages cannot be received in the AUv3 format.
Hi @reuk!
I tested JUCE MIDILogger and also created a MIDI monitor using CoreMIDI.
I’m able to see SysEx messages with Native MIDI monitor, but not with MIDI Logger.
Yes, this works in reaper. We tested all possibilities in Logic X (on macOS), but our AUv2i instrument wasn’t able to receive any sysex. I thought this is a limitation of Logic, but this post makes me hope that there is something we can do about it.
