Dropped and duplicated sysex start/end bytes

[zkf]

Hi, I am working on a patch editor for a hardware synth and while handling sysex data I spotted a couple of issues with the sysex input stream. Both the [midiin] and [sysexin] objects have issues with either dropping or duplicating some of the bytes coming in, but it does not happen in all variants of PlugData.

I did some testing and here’s what I found, for [midiin] and [sysexin] respectively:

[midiin]

The leading byte (240) is duplicated. This happens in the VST3 variant in Reaper on Windows 11 and in the VST3 variant in Ardour on Linux. I also tested the LV2 variant in Ardour on Linux and the standalone variant on both platforms; they did not display this behaviour.

[sysexin]

• The VST3 variant in both Reaper on Windows 11 and Ardour on Linux: chops off the end-of-sysex byte 247 from the stream.
• Standalone variant on Windows 11 and Linux, and LV2 in Ardour on Linux: both the start and end bytes are missing.

Thanks for creating this!

[timothyschoen]

Thanks for reporting! I copied the MIDI code from Camomile, and have made very little modifications since, so I wonder if this affects Camomile as well. It's very surprising to see that it behaves differently across different plugin formats, make me worry that this is a problem in JUCE.

I found this problem with sysex output from a VST3: https://forum.juce.com/t/some-info-re-sending-out-midi-system-exclusive-messages-from-a-vst3/38662/2 It might be related.

[zkf]

I never used Camomile before now, but I tried modifying the default Bulgroz patch to print incoming sysex messages. I had no success in Ardour, there was no output.

Yep, there could be problems with sysex output like what you linked to, but I haven’t gotten around to test that yet :) I just recently started learning pd.

Edit: Ah, I guess this Camomile Bulgroz patch has MIDI disabled

[zkf]

I’ve tested the [sysexin] object in Camomile now, and I can confirm that it exhibits the same behavior for the VST3 and LV2 plugins (tested in Ardour on Linux).

[timothyschoen]

Thanks for checking!

I did find this code that handles sysex messages, there might be something wrong there, I'll take a look at it soon.

[timothyschoen]

I can reproduce this issue. The behaviour in the standalone is expected, cutting the first and last sysex bytes off is okay because that's the "this is sysex" flag.

The fact that the VST3 does output the first byte with [sysexin], while the [midiin] outputs a double first byte and end byte makes sense, they are both the result of a doubled first byte (but then [sysexin] then removes the first and last byte).

I suspect it's related to this issue:

https://forum.juce.com/t/some-info-re-sending-out-midi-system-exclusive-messages-from-a-vst3/38662

The problem is that apparently, the VST3 specification is unclear about how this should be handled.

[timothyschoen]

Since this is a ambiguity in the VST3 MIDI definition, I'm gonna close this. There is no way we can solve it, if we would test if the first bytes of the message are the sysex start bytes, we could also accidentally remove a part of the message, there is no way to know.