Creating SYSEX

Hi,
I’m trying to send a sysex from a plugin i’m developing, but I only succeed if its dimension is standard three bytes (including start 0xF0 and end 0xF7), so it’s not very useful. All others midi messages works great.

My code is something like:

struct _sysex {
LV2_Atom_Event event;
uint8_t byte[4];
} sysex;

uint32_t OUT_capacity = MY_OUTPUT->atom.size;
lv2_atom_sequence_clear(OUTPUT);
MY_OUTPUT->atom.type = MY_INPUT->atom.type;
memset(&sysex, 0, sizeof(_sysex));
sysex.event.body.size = 4;
sysex.byte[0] = 0xF0;
sysex.byte[1] = byte_1 & 127U;
sysex.byte[2] = byte_2 & 127U;
sysex.byte[3] = 0xF7;
lv2_atom_sequence_append_event(MY_OUTPUT, OUT_capacity, (LV2_Atom_Event*)&syses);

Any help will be precious!

Update test:

  • I have created two different plugins: the first sending a sysex of lenght > 3, the second reading sysex. Communication between the two plugins through sysex is OK. So it seems not to be a plugin problem.
  • I send a sysex > 3 inside the DUO through usb midi port: my plugin receives it perfectly. So it seems not to be an host’s midi-in problem.

The problem is that sysex > 3 can’t pass through host’s midi-out port. Is it a host bug?

2 Likes

Anyone has an idea? It’s a host bug or I missed something?

Sysex is currently not supported when passed through the MIDI DIN ports.
(something we still need to implement)

Should work if you use USB MIDI though.

It works through USB MIDI port, thanks.

It seems to have similar problem using netjack: all values of the SysEx message I receive on the slave machine are set to 0. Is it the same problem?

No, the DIN MIDI has a custom midi parser where we skipped the sysex initially in order to save time for other features.

on the netjack I have no idea at the moment…

Is system exclusive still no go on the DIN ports?

that is correct

1 Like