You've already forked ivan-torvalds-GuitarPedal
forked from AllSpiceMirrors/torvalds-GuitarPedal
db24ff6182
Two bugs going opposite ways through the hardware MIDI port, both from the same missing piece: nothing worked out what a USB-MIDI Code Index Number should be, so each direction guessed separately. Coming in, uart_midi_read() set packet[0] = 0 and uart_midi_poll() forwarded that to the host. CIN 0 is reserved in USB-MIDI 1.0, so every message arriving at the TRS jack and passed through to USB was malformed and a host was within its rights to drop the lot. handle_midi_packet() coped, because it reads the status byte rather than the CIN, which is why this could sit there looking like it worked. Going out, uart_midi_write() had its own switch listing 0x8, 0x9, 0xB, 0xC, 0xD and 0xE, and threw away anything else. 0xA - poly key pressure - is a perfectly ordinary channel voice message and was simply dropped, as was every real-time byte, so MIDI clock arriving over USB never reached the TRS out. Song position and SysEx went the same way, though nothing generates those down this path today. So write the two halves once, next to each other where they can be checked against one another: what CIN a status byte belongs in, and how many bytes a CIN carries. Note that none of this is built by default - it is all behind MIDI_HW - which is precisely why a table of sixteen cases could be wrong for as long as it liked. So there is a host-side test for it in Validation/ alongside the FFT one, checking the mapping and the round trip for every channel-voice status byte. 'make check' there runs it. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
4 lines
35 B
Plaintext
4 lines
35 B
Plaintext
test-fft
|
|
__pycache__
|
|
test-midi-cin
|