How to properly send SysEx messages

[theacodes]

Hi, I'm trying to send sysex messages from tinyusb to a connected computer.

However, I can't seem to figure out the proper way to do it. I tried using tud_midi_send with the proper USD MIDI event packets:

tud_midi_send((uint8_t[4]){0x04, 0xF0, 0x00, 0x01});
tud_midi_send((uint8_t[4]){0x07, 0x02, 0x03, 0xF7});

However, MIDI Monitor shows that this comes across as invalid data:

I've tried with tud_midi_write using a plain sysex message, as it seems it has logic to handle that:

tud_midi_write(0, (uint8_t[6]){0xF0, 0x00, 0x01, 0x02, 0x03, 0xF7}, 6);

But this is incorrect as well:

[theacodes]

Actually, I'm generally just seeing a lot of weirdness with sending messages from my device. Receiving messages seems fine. But I've noticed that if I send more than one message, sometimes they don't get sent until after I send additional messages, and then those get held until I write more, and so on.

For example, I'm sending 3 CC messages in response to a single SysEX message:

tud_midi_send((uint8_t[4]){0x03, 0xB0, 0x5A, (result >> 12) & 0xF});
tud_midi_send((uint8_t[4]){0x03, 0xB0, 0x5A, (result >> 8) & 0xF});
tud_midi_send((uint8_t[4]){0x03, 0xB0, 0x5A, (result >> 4) & 0xF});

This log shows the behavior: every y is when the device is sent a message, each printed tuple is a message back from the device. You can see that the first message sent only gets one in reply right away, but once I send the second message there's three responses. Two of them are actually from the previously sent set of messages, and one of them is from the current set of messages.

y
([176, 90, 0], 0.0)


y
([176, 90, 15], 37.237949515000004)
([176, 90, 15], 37.237949515000004)
([176, 90, 0], 37.237949515000004)


y
([176, 90, 1], 73.35141262100001)
([176, 90, 7], 73.35141262100001)
([176, 90, 0], 73.35141262100001)

[hathach]

@theacodes I have revised and improve midi driver, would you mind trying it out here to see if that fixes your issue https://github.com/hathach/tinyusb/tree/improve-midi

Note: MIDI driver is based on cdc, but since it is much less used, it also got less PR/update than cdc.

[theacodes]

Seems that branch helps with the simple messages above:

y
([176, 90, 1], 0.0)
([176, 90, 2], 0.000307125)
([176, 90, 3], 0.000307125)
y
([176, 90, 1], 1.173538513)
([176, 90, 2], 0.000331076)
([176, 90, 3], 0.000331076)
y
([176, 90, 1], 0.9214775070000001)
([176, 90, 2], 0.000272757)
([176, 90, 3], 0.000272757)

And with SysEx

y
([240, 0, 1, 2, 3, 247], 0.0)
y
([240, 1, 1, 2, 3, 247], 2.854390695)
y
([240, 2, 1, 2, 3, 247], 0.6649876130000001)
y
([240, 3, 1, 2, 3, 247], 0.7598042)
y
([240, 4, 1, 2, 3, 247], 0.7838369390000001)
y
([240, 5, 1, 2, 3, 247], 0.558254569)

Thank you, @hathach!

[hathach]

@theacodes I am glad that helps you, let's me know if you still have any other issue with MIDI driver. You could keep this issue opened until you got it all sorted out. Then we could merge that midi branch into master.

PS: I am noob with MIDI and instrument therefore the driver lack needed testing.

[theacodes]

Sounds good. Happy to keep testing the MIDI driver, and feel free to cc me on the PR for this. :)

…

On Mon, Aug 24, 2020 at 1:34 PM Ha Thach ***@***.***> wrote: @theacodes <https://github.com/theacodes> I am glad that helps you, let's me know if you still have any other issue with MIDI driver. You could keep this issue opened until you got it all sorted out. Then we could merge that midi branch into master. PS: I am noob with MIDI and instrument therefore the driver lack needed testing. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/hathach/tinyusb/issues/495#issuecomment-679265980>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5I44MCXTBZQJ5WNYXA23SCKQBRANCNFSM4QJBGVFQ> .

[mzero]

I think I found the bug!

If you send [0xf0, a, b, c, d, e, f, g, h, i..., z, 0xf7] (where the letters represent arbitrary payload values)
you get instead: [0xf0, a, b, c, a, b, d, a, b, e, a, b, f, a, b, .... z, a, b, 0xf7, a, b]
if you space that out in the three bytes of payload in each USB packet, you'll see the pattern:

[0xf0, a, b,
    c, a, b,
    d, a, b,
    e, a, b,
    f, a, b,
    .... 
    z, a, b,
 0xf7, a, b]

This is a bug in the USB MIDI encoder in tud_midi_n_write():
https://github.com/hathach/tinyusb/blob/master/src/class/midi/midi_device.c#L186

This line is wrong. It is

                midi->write_buffer_length = 4;

should be

                midi->write_target_length = 4;

[mzero]

I wrote my finding up as a separate bug (#511) and pull-request (#512) - since I'm not certain it fixes everything originally reported here.