Fix a bug in writing SysEx messages.
At the start of a new USB packet (4 bytes), while in the middle of a SysEx, the code mistakenly
set the buffer length to 4, not the target length. As a consequence, the 3rd and 4th bytes from
the last packet were included, after every byte of the SysEx after the first packet of three.
The fix is simple, as it was just a typo, as can bee seen from the other branches in the same
section of if/else statements: At the start of a new packet, the code should set up the target
length... the buffer length should be left at 2 (as set on line 180).
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.
Reinhard Panhuber