Larger SysEx transfers get corrupted by incoming packets.
This changes the FIFOs not to overwrite their data. MIDI should not be
a transport that drops packets. A potentially blocking device is easier
to detect and handle than a device that silently corrupts the packet
stream at random overflows, especially when SysEx messages are involved.
This changes the internal buffering to the raw 4-byte messages. The
conversion of the messages to a byte-stream moved to the read/write
methods.
It adds a raw packet interface to send and retrieve the raw 4-byte
USB MIDI message:
static inline bool tud_midi_receive (uint8_t packet[4]);
static inline bool tud_midi_send (uint8_t const packet[4]);
MIDI USB packets carry virtual cable/wire/plug data in the packet header,
which cannot be exported in the byte-stream interface. The raw packet
interface allows to send and and receive the complete USB message.
.. sending these as two 1-byte messages with CIN of 0xF is
misinterpreted by OSes including Windows 10 and (reportedly)
Mac.
Testing performed: Ran the reproducer script, which sends Program
Change (0xCx) messages. I did not check with Change Pressure (0xDx)
messages, but expect the same thing.
Closes: #98
Fifo incurs a second copy into a USB buffer but this ensures the
correct USB buffer alignment. Some LPC chips require 64 byte
alignment that txbuf couldn't do.
