This article describes my enhancements of the MIDI standard and shows ways to get around several issues by increasing transmission speed and controller resolutions. See this example for an explanation here

The problem is, that even with enhanced MIDI at 230k like I proposed it here, precise piano playing is not possible. Also with interfaces like USB at PCs, there will still be a bottle neck and latency when transferring music data to the sound device. The orchestral case, using 32 or 64 voices and intensive controller activity cannot be handled by the MIDI protocol. Latency should not be the big problem during offline work like production, but bandwidth is. The density of orchestral music ranges between 10% and 50%, so the number of voices simultaneously active is about 5 to 30! even for small orchestral music. Including controller values and sysex, around up to 100 midi messages will be required within the critical 2..3 ms period. Allowing 5ms for maximum delay, a 1MB connection will be required. According to the table more than 16000 events could be transported per second which will work for most applications.

Anyway, to reduce the time and also increase the resolution of the controllers, I thought of a new protocol adding 2 more bytes which contain addition resolution bits or could contain other pieces of information and replace the serial slow protocol by physical S/PDIF.

Using 5 Byte MIDI solves the issue of the coarse controller values since 12 bits are available now. Using S/PDIF physical layer at least 3MBaud are available to transmit MIDI data with acceptable delay and sufficient precision. Using 10 Bit reduced MIDI like in the 10 Bit MIDI Controller, 2 MIDI messages can be compressed into a S/PDIF word of 32 Bits. Alternatively two S/PDIF words can be used to store MIDI raw data including start / stop and parity bits for easy decoding. Finally full 5Byte MIDI can be transmitted using external S/PDIF connection using the normal protocol. 

  Read also the former article about the limitations of MIDI.