96 kHz.org
Advanced Audio Recording

The Limits of MIDI

This article deals with the limitations of the MIDI standard in terms the controller resolution and transmission bandwidth. It is a copy of my german article here:  Probleme bei der MIDI-Übertragung

 

 When having a closer look at synthesizer playing, one observes that it is nearly impossible to transport all the information for e.g. 8 simultaneously pressed keys appropriately using the current slow MIDI protocol. It was defined more than 15 years ago now and was designed for monophonic musical instruments like synthesizers in the first place. Todays' instruments are polyphonic and have a lot of features which can (or must ?) be modified in real time. This requires a higher bandwidth which MIDI as defined in the early 80tees does not allow. It runs at 31kHz only and because of the typcial 3-Byte-structure of the protocol it causes nearly 1ms delay for one single message!

This is an abolute limiter for the usage of MIDI together with intruments which require detailled control of their parameters like guitars, flutes or special instruments like the Theremine. Some years ago I talked to Oskar Sala, the inventor of the Trautonium and found he heavily complained too about the coarseness midi.

This is the reason why people think af alternatives. One solution are "to host" interfaces like known from several keyboards. The work with RS232 or simliar standards using higher bandwidths. I am e.g. using up to 232kbaud in controllers. To improove data security 2 stop bits are used eventually. Here are some examples:

 

MIDI Protocol Options:

Comparison of different MIDI protocol speeds

The table above assumes 10 keys pressed the same time and shows the duration, after all the note start commands are transmitted. One should expect that this must be done within some milli seconds in maximum, since the micro processors in both instruments will add even further time delay This does not work for more than 3-4 keys in real time. Furthermore, synthesizers will have to send a lot of controller data in order to control the voices in real time and perform modulations which are not done automatically. They also do not necessarily have to use sustain voices but like to see the note stopping immediately after releasing the hand especially when using voices like pulsed square waves with hard attacks. The issue is, that for changing keys and controllers, "note off" information must be sent for individual keys while there is only little time to do this when the hands change to other positions. In rare cases notes will stay on too long and last up to a point of time, when new keys are pressed again.

 

MIDI Jitter - the result of the low bandwidth

 This happens very easily when using real time arpeggiators or quick 1/32 notes and high speed like required for techno. At tempo with 160 bpm, a 1/32 note will repeat at 50ms period and last for e.g. 20ms having 30ms pause. Playing a chord will make any jitter very obvious! Read here about other issues of jitter in audio systems.

example of jitter with MIDI

To overcome the strongest limitations and make it possible to play with one hand under full controller support with synthesizers, this leads to 5x2 = 10 + 5 controllers for SYSEX messages the same time. Under the requirement of transmitting this information with less than 2ms latency, 200kBaud are necessary while MIDI today still acts under the outdated 31k specification!

 

Standard 230k Serial Interface used for MIDI

For demonstration, I created a 230 based MIDI controller, using serial protocol and interfacing to a PC. This demonstrator suffers from the slow data treatment caused by Windows (up to 100ms delay) which will not be the case when using a modern microcontroller like a 68HC05 or similar to interface to common Motorola DSPs. As a test, I implemented a 230k MIDI in a TMS 320 architecture by simply speeding up the frequency by ratio 8 x 31.250kHz leading to 250k. It worked with no problems. For transmission tests I add another stop bit to achieve something like 230k effectively. See the table above for speed values.

230k were chosen, because this is the standard limit of the PC Uarts and therefore such transmission circuits are available in masses. To be honest, 230k do only work with a quick windows driver at all and this would be the first demand for the PC GUIs using a MIDI device like a Synthesizer running on 230k MIDI clock. Also cable lengths should be kept below 1m to ensure proper operation. Therefore I added a half speed protocol at 115k as a proposal for a speed at 3 times the existing rate in column 2 of the table. To achieve 230k speed with full security, symmetric transmission like used with the digital AES/EBU busses should help. In most cases, a twisted pair wiring already made transmission fine according to my tests.

 

It's time for MIDI 2000

Having a look at good qualified piano players, it becomes evident that finger movement has to be very precisely reproduced in order to maintain the information. One cannot use simple velocity curves but as to sent continuous controller information with at least 1kHz along the transient time of the note. This leads to what I call the "piano 10 finger problem" which means, that 10 controllers must be sent in less than some ms and at least 20 have to be sent during note start leading to 30 midi messages at the "same" time. So even with enhanced MIDI 230 like proposed, this was impossible.

Anyway more speed was better in any case, so one should think of higher rates. The PC's limit seems to be 460kBaud, which I achieved using Linux and the wxWidgets Library. See my PDF-document here for a detailed explanation. www.iftools.com (CTB library). With 460kBaud piano control in real time is principally possible with special hardware, even 920kBaud is possible using Linux. So from the PC side, it was possible to switch to an enhanced MIDI standard with increased speed. I'd love to see at least a 460kbaud implementation for MIDI as e.g. "MIDI 2000".

 

Read about another idea of sending MIDI as Audio.

 

 

© 1999 - Jürgen Schuhmacher