You are reading a single comment by @indianajones and its replies.
Click here to read the full conversation.
-
@allObjects I agree with @Robin.
Getting a reliable 'pipe' going may be a challenge...
Most of the time, my code will be on the receiving end of MIDI data, and most of that will be a burst of NRPN messages after initial connection, and then mostly quiet. So far, so good on that front, but it's still early - plenty of time to screw things up ;-)
indianajones
The conversation starts out with
and that is what guided my response.
That MIDI - at least the initial prevailing standard and not the newest draft - deals with 7 bit values only is actually great to be able to introduce meta data in the transport layer which can easily be filtered out: MSBit 0 means destined for the MIDI layer, MSBit 1 means control data for the transportation layers. I'm aware of that the stream of MIDI data is most likely time critical and therefore too much meta data in the stream may be a challenge... except the transport layer is so much faster that it still can sustain the 31.25kbps above it (for the MIDI endpoints - source and sink).
Your experience switching between both the plain and clamped unsigned 8 bit array is explained now explained why you have same results. From a point of speed the clamping may time-wise not be noticeable since it is done internally on firmware level and not on the (much slower) JavaScript level. Great is that all arrays have the same protocol...
Getting a reliable 'pipe' going may be a challenge, because you do not have much control over the packages. Adding that would have to be with a fast implementation and I'm thinking about compile JavaScript or even embedded C. That piece of fast code could insert frame information on the sending side and filtering out on the receiving side in order to give you control over the pipe... and drop failing packages without real big consequences since the transportation layer package boundaries can be made aligned - logically - to the payload package boundaries. With sockets you could even think of retransmitting packages that are not allowed to be dropped / skipped... or double / triple down on sending them... and on the receiving side to pass on only the one...
To be frank, I do not know what is or can be critical in a MIDI stream from point of data loss / corruption and tolerance thereof, so take my thoughts as general thoughts of getting data reliably from one end-point to another one.