[sdiy] Techniques for Multiplying MIDI Clock frequency?

[Brian Willoughby]

Yes, the first byte is unique to USB-MIDI, and combines the Cable Number and CIN. They call that byte a Packet Header. Remaining bytes are entirely defined by MIDI (except unused bytes). Given that USB-MIDI requires every 32-bit event packet to have a complete MIDI message (barring System Exclusive), it's generally possible to parse just the remaining bytes to determine the length according to standard MIDI rules, but obviously not in all cases. In particular, you could probably just look only at the second byte (the first MIDI byte) and would (almost) always know the length of the message.

The very first open-source USB-MIDI Device firmware that I saw hard-coded the CIN in such a way that it conflicted with the actual MIDI content. Apparently, all of the USB Hosts that were tested with this particular USB-MIDI Device firmware were ignoring the CIN, some or all of the time. Either that, or the firmware was completely untested (which I doubt).

I don't recall where that open source USB-MIDI firmware is, but I seem to recall that all MIDI Channel Messages were coded with CIN=8. This implied that all Channel Messages were Note Off. I guess this worked because the USB Host driver for USB-MIDI was ignoring the CIN and looking at the actual MIDI data to determine the message type and length.


That particular bug convinced me that one should never design a protocol or format with redundant information, especially if there is no rule for which piece of redundant information takes precedence in the event that they do not match. I had already been convinced that, in software, if something can be wrong with incoming data then it will be wrong at some point in time.


Granted, USB itself has redundant information in a particular byte, where the upper 4 bits appear flipped in the lower 4 bits. However, this is not strictly redundant information because it's used as a check. When those bits don't match correctly, the USB protocol states that the data should be discarded. USB-MIDI just quite assumes the redundant bits will always match, with no defined result in the cases where they do not.

Brian


On Dec 24, 2021, at 08:26, MTG <grant at musictechnologiesgroup.com> wrote:
> Hi Brian, can you explain this a bit please? Do you mean the CIN Code Index Number at the start of the packet (Eg. 0x8 for Note On) and then the first data byte that follows? I never considered that they might not be the same, but I suppose one uses the CIN mainly to get the length of data and then parse the MIDI using classic techniques.
> 
> On 12/23/2021 9:57 PM, Brian Willoughby wrote:
>> (although I always thought it was a severe oversight that the USB-MIDI message has the same 4-bit command encoded twice in every message, making it rather difficult to know which one to honor if they happen to be different).