Protocol (Part 1)
Everything you ever wanted to know about the MIDI standard but were afraid to ask - Paul Overaa explains all
In the first instalment in his series on the MIDI protocol - Paul Andreas Overaa takes us through the background behind the birth of the standard and its fundamental workings
MIDI, as all Micro Music readers should know, stands for 'Musical Instrument Digital Interface'. It is a communications framework that was designed to provide standardized digital communications between synthesizers, drum units, sequencers, effects units and anything else that the performing musician is liable to use. Before the adoption of MIDI the majority of musical equipment manufacturers set their own standards for such things as gate protocols and oscillator control voltages and a direct consequence of this was that linking equipment from different manufacturers was quite simply a pain - if things worked O.K. you were lucky, most of the time it was a nightmare unless you stuck to a few well established combinations. When sequencer and drum units came on the scene the situation got worse... now we had a collection of individual 'standards for clock rates', i.e. timing signals, and this just compounded the existing difficulties.
For a few years various 'band aid' solutions were offered and there were plenty of companies around who produced conversion boxes which let you translate timing data or signal levels between different manufacturers formats - but these had limited success, were still manufacturer specific in many ways, and certainly didn't offer a long term solution to the problems.
The real problem was not that any of the major manufacturers had 'bad' standards, it was just that they all seemed to adopt different ones, so each manufacturers 'standards' were only coherent within the realms of their own products. From the working musician's viewpoint this situation wasn't ideal and I for one remembering buying early drum machines which provided no end of problems and I know synth players with half a dozen keyboards that would simply give up on stage when things went wrong - because neither they, nor anyone else, would (or could) tackle timing/control problems whilst out at a live gig.
As more and more products appeared manufacturers began to realize that the standardization problem was getting worse and some real effort was going to have to be put into finding a workable, and cost effective, solution. What happened was an example of the ways things should be done... the major manufacturers, from the States, Germany, Japan, and the U.K. etc., got together to produce a working framework which aimed to allow all types of equipment to use a common communications protocol. The end result was that fast serial transfer, based on optically isolated shielded twisted pair cable links, would be used to transmit digital data using a well defined, but flexible, multi-byte message protocol... MIDI was born!
The first specification I saw actually came from Sequential Circuits, during 1983 in a document outlining the essential details of the 'MIDI 1.0 specification'. You'll often read the odd 'niggle' about the MIDI standard and may also hear people saying that 'such and such would have been better if they'd done it this way'. It's true that there are some parts of the MIDI standard that could be improved but on the whole the committee that steered the formulation of the spec got it as near perfect as one could expect and this is obvious from the overwhelming acceptance of MIDI by both musicians, manufacturers and the music industry in general. Anyone who's had experience of other communications protocols, such as RS232CA/21A/22A/23 serial communications, will know that this is true.
MIDI messages are sent as streams of serial data. Each eight bit 'byte' is sent as a start bit, eight data bits, and a stop bit at a speed of 31.25 KiloBaud... that's about one byte of MIDI information every 320 millionths of a second. Because the data is in digital form, as opposed to being an analogue signal, it's far less prone to distortion or interference and this means that cables between each piece of equipment can be up to 50 feet long. In practice it's still best to keep cables as short as possible - if nothing else it makes it quicker to pack your gear up! Once you're familiar with what MIDI is, what it does, and what spells have to be said before you go out working live with MIDI gear you'll find very few problems in practice. The odd difficulty that does arise is often something simple, such as having a channel set incorrectly or plugging one of your leads into the wrong socket.
As you know MIDI equipment usually has two or three 'five pin' DIN sockets. The terminal marked MIDI IN is where the equipment receives it's MIDI data, that marked MIDI OUT is where data is transmitted. Usually you'll also find a MIDI THRU socket and this provides a duplicate of whatever is being received at the MIDI IN terminal. Not all types of equipment will understand all types of messages, nor does every piece of MIDI equipment send every type of message but this doesn't usually cause much in the way of problems - providing you know what types of messages your particular equipment is capable of sending and understanding. There's a couple of general points that are worth mentioning here because they often cause confusion: Firstly MIDI sends it's information in eight bit units. The computer world calls these 'bytes' and a byte can represent a letter, a number, a computer instruction or anything else - providing it can be coded as one of the 256 patterns which an eight bit binary number can represent. MIDI communications are best regarded as being streams of eight bit numbers and it's the MIDI standard itself which has defined a particular number, or set of numbers as having a certain meaning.
The MIDI standard uses one of the bits present in any MIDI byte to distinguish between status bytes and data bytes... Status bytes always have the high bit (bit 7) set, i.e. they range from 1000 0000 binary to 1111 1111 binary. Status bytes are important because they allow the equipment to identify what class of message is being received, i.e. each status byte is either a complete MIDI message or it identifies a particular class of multi-byte MIDI message whose data bytes are about to follow. Because bit 7 is used to indicate a status byte all data bytes which follow are restricted to values ranging from 0000 0000 binary to 0111 1111 binary, i.e. decimal 0 to decimal 127.
The second general point is that MIDI recognizes the existence of sixteen separate channels. A large class of MIDI messages, known as Channel messages, contain a channel number encoded within the status byte of the message. The overall effect is that it allows pieces of equipment to be selective about certain types of messages they send, receive or make use of.
This is why we can now have drummers, sequencers, synthesizers etc., all attached to each other via a single MIDI communications cable loop - by setting up each unit to respond to a different MIDI channel we can send all of our MIDI messages down the one MIDI line knowing that each unit will respond to only those messages that have the matching channel number identification. It's a bit like someone writing a letter to you, sticking it in an addressed envelope and posting it - the letter, along with thousands of others, gets shifted around the postal system but, as far as reading the contents goes, it is essentially ignored until it arrives at your door, i.e. it's final destination. You know the letter is for you because it's got your name and address on it - MIDI units know when a channel message has arrived for them because it will have a suitable channel number built into the message.
MIDI at the highest level distinguishes between the channel messages just mentioned and messages of more general interest to the system. These latter 'System messages' fall into three sub-categories... Real Time, Common, and Exclusive and it's these that we'll have a look at next month!
Feature by Paul Overaa
Previous article in this issue:
Next article in this issue:
mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.
If you value this resource, you can support this project - it really helps!