Inefficient MIDI transmit

[PaulStoffregen]

We're sending only 4 bytes of data for every outgoing MIDI packet, leaving the other 60 unused.

Someday this should be done like Teensy's USB MIDI device support, where we wait until the next SOF to pack more messages into the outgoing packet. Or maybe a short timeout could be used to flush the partially filled outgoing packet?

[doctea]

This is an old issue, but am I right in thinking that this is implemented in the newer versions of the library? (My experiments and sniffing around in the code seem to indicate so).

Unfortunately, this seems to lead to the side effect of MIDI clock being unstable/unusable -- presumably because the library is waiting for the buffer to be filled before sending. Because MIDI is a realtime protocol, those delays make the library unusable for most purposes (I'm making a device that will act as master clock and interface between many USB-DIN and USB-MIDI devices).

I would assume that the send_now() method could be used to flush the buffer immediately after sending the Clock message, but it actually doesn't seem to do anything at all?

What's peculiar is that this problem doesn't seem to affect the first USB-MIDI device to be sent clock -- only devices after the first!

This problem and workarounds are discussed a little on the forum thread here: https://forum.pjrc.com/threads/70026-Sending-Midi-Clock-to-multiple-objects-with-USBHost

Thanks,

[insolace]

Our devices have a send buffer that is filled as needed and checked/sent every millisecond. This is pretty crucial to preserve the timing of real time messages (ie clock) as well as maximizing bandwidth.

[PaulStoffregen]

Opened new issue #86 for this.