JUCE VST3 Sysex MIDI Bug

[kunz]

JUCE VST3 Sysex output does not work in 3rd party hosts. JUCE strips out the header and footer Sysex bytes. Because of this, Sysex output from VST3 plugin does not work in most hosts including Cubase 12 and Reaper. So far the only reported host where it works is the JUCE host itself.

Reproduce the problem with Steinberg Cubase 12:

• Disabled the SySex MIDI Filter in the Cubase settings
• Create an Instrument Channel with the VST3 that outputs Sysex from the process block
• Create a MIDI Channel in Cubase
• The MIDI Channel receives the Instrument Plugin MIDI output
• Enabled MIDI Channel Monitoring to forward the MIDI message
• Record the Sysex MIDI in the MIDI Channel
  → The recorded MIDI is empty because Cubase ignores the Sysex data because of the missing header and footer bytes

It can also be tested in Reaper in a similar way.

Sending the raw MIDI data, including the header and footer bytes, fixes the problem (juce_VST3Common.h) :

static Steinberg::Vst::Event createSysExEvent (const MidiMessage& msg, const uint8* midiEventData) noexcept
{
    Steinberg::Vst::Event e{};
    e.type          = Steinberg::Vst::Event::kDataEvent;
    // e.data.bytes    = midiEventData + 1;
    e.data.bytes    = midiEventData;
    // e.data.size     = (uint32) msg.getSysExDataSize();
    e.data.size     = (uint32) msg.getRawDataSize();
    e.data.type     = Steinberg::Vst::DataEvent::kMidiSysEx;
    return e;
}

Another thread about this topic:

Some info re: sending out MIDI system exclusive messages from a VST3

I just wanted to share an issue I encountered with the way Juce adds MIDI system exclusive messages to the VST3 wrapper’s outgoing event list. I wouldn’t say it’s a bug, but it is something you should be aware of if you want to output SysEx messages from your plugin. The relevant code for this resides in juce_VST3Common.h lines 560 to 566: else if (msg.isSysEx()) { e.type = Steinberg::Vst::Event::kDataEvent; e.data.bytes = midiEventData + 1; e.data.size = (uint32) m…

[dev1am]

Another thread here:

MIDI SysEx messages

Hi, it seems that if the plugin receive SysEx from a MIDI track (getting data from getSysExData()) the plugin receive F0 twice. const uint8* MidiMessage::getSysExData() const noexcept { return isSysEx() ? getRawData() + 1 : nullptr; } in my code I’ve try to debug with this: if (midiMessage.isSysEx()) { const uint8* sysexData = midiMessage.getSysExData(); DBG("sysexData[0]: " + String(sysexData[0])); } and I can see that if I receive the SysEx message from a MIDI track loading my…

When receiving the SysEx message from a MIDI track in a DAW, the value of sysexData[0] is F0 instead of the byte after F0, in my case I solved adding an “offset”

int offset = sysexData[0] == 0xF0 ? 1 : 0;

[kunz]

@dev1am

sysexData[0] is F0

I’m not sure what happens here. This doesn’t look right. I also have to process incoming Sysex messages in the next few days. We will see how this goes. So far my report is only about sending Sysex with VST3. VST2 seems to work as expected. Didn’t test AU.

At least there is a workaround for this while we have to modify the JUCE wrapper code to make sending Sysex with VST3 work.

[kunz]

I can confirm that receiving Sysex with the VST3 also does not work because JUCE adds the header and footer again as described here: MIDI SysEx messages

The assumption that the VST3 format works without Sysex headers is wrong. The JUCE host is the only one that handles it that way.

The fix is easy. JUCE should not remove and re-add the Sysex header and footer bytes in the VST3 format. Just leave the Sysex message like in the other plugin formats.

A few people already reported problems with Sysex and VST3 in the last few years. It does not work the way it is implemented today.

It would be great to have this fixed in the JUCE branch.

[reuk]

Thanks for reporting this issue, it should be fixed here:

VST3: Include header/footer sysex bytes when converting with DataEvent

[kunz]

Great Thanks for the fix.