[Feature] Consider optional MIDI 1.0 data speed throttling service plugin

[Psychlist1972]

Many older MIDI 1.0 devices do not handle data flooding well. The driver doesn't know that messages are being dropped/discarded.

Investigate

• A property that can specify that throttles messages to a device to a certain speed (default 31250 bps apx)
• UI for the setting
• A service plugin that queues up those messages
• Possibly a setting for the initial buffer size (per device), if we use fixed buffers

Considerations

• Can't conflict with message scheduling
• Related to and/or impacts multi-client SysEx parking Consider adding Multi-client MIDI SysEx collision handling to the service #60
• Can possibly be per-group (and use info from the group terminal block speed) rather than just per-device

[easypx]

I did some research on the USB MIDI adapter market. The problem with sysex only seems to affect certain cheap, older adapters. (probably buffer too small, processing speed too low, no custom driver). There are now plenty of alternatives that cost a little more, but work. My last research was 10 years ago and there was really only a small selection, but a lot of these cheap Chinese imports and I have 3 of these cables myself. Time to buy a decent adapter. You can still use these cables for sysex with the software https://www.bome.com/products/sendsx
I think that integrating a fix (slowdown) for this into an operating system driver is not really a priority, also because of the possible difficulties described. From an operating system developer perspective, USB standards are adhered to. How the adapter handles this should be the responsibility of the hardware provider.
Here is a hardware fix that adds an optocoupler to the input, which should be there due to MIDI specs. I don't think this is the only problem with all these iterations (it is actually an unexpected, new problem), but it's worth a look.
http://www.arvydas.co.uk/2013/07/cheap-usb-midi-cable-some-self-assembly-may-be-required/