I see it more as “running status ceases to exist” as soon as a MIDI stream hits a USB connection.
The connection is still transparent because no data is lost, in fact, you get some reconstructed data for free.
At first, you would think that.
Until you look at the handling of sysex in the example.
There are actually 3 different Code Index Numbers for a sysex message that ends with 1, 2 or 3 bytes.
If padding with zeroes was automatically recognised, this wouldn’t be necessary given that the 'end of sysex', 0xF7
is also present in the event packet.
It seems that way, until you realize you need a Status Byte anyway for setting the Code Index Number.
And if you’re converting from DIN to USB, you’re already keeping track of the last Status Byte in case the device on the input uses running status.
If it was actually efficiently implemented, you would be able to send those 8 midi messages with running status in 6 packets instead of 8.
What seems more inefficient to me is that in most cases, the first 4 bits of the Status Byte sits twice inside the 32 bit Event Packet.
Or why do we even need Code Index Numbers? MIDI DIN works fine without them right?
I think it comes down to some internal logic in the way USB controllers work, and most processors calculate with 32 bits minimum so there’s a connection there.
Transmitting MIDI this way also seems less prone to errors, since you know exactly what information will be in which place, so no extra interpretation of the data is needed.
Oof, sorry for the long and post.