In anticipation of future articles on using MIDI in the studio, our own Simon Trask sets out the basics.

The term MIDI is becoming a part of everyday musical terminology for an increasing number of musicians, and its already significant applications within a recording environment are now being extended by the new generation of MIDI-compatible rack-mounting effects units spearheaded by Roland and Yamaha.

The uses to which MIDI could be put within a recording context were touched on by Steve Howell in last month's 'It's all done by Planning' article, but if you're not familiar with what MIDI actually is then you might well be feeling slightly confused. With this in mind, it seems a good time for H&SR to present a guide to MIDI. Being nothing if not thorough, I've gone for a bit of an information overload - but then if you can't read about it in H&SR where else is there (apart from H&SR's sister magazine E&MM). Well, that's the advertising over with, now down to work.

Background

The original impetus for MIDI (or the Musical Instrument Digital Interface, to give it its full title) came from American manufacturers Sequential Circuits back in 1981. The specification that they developed for a 'Universal Synthesiser Interface', and first presented at the Fall 1981 convention of the Audio Engineering Society, was basically limited to the serial transmission and reception (at 19.2 kBaud) of note on/off data.

A subsequent conference at the January 1982 NAMM convention, attended by many of the major manufacturers, increased the speed of the interface to 31.25kBaud and added opto-isolation to the interface hardware to prevent ground loops.

Following this meeting, some of the Japanese companies presented an alternative specification which defined more complex operations and offered a data structure which flagged status and data bytes by bit seven, with one meaning status and zero meaning data (if you find this a trifle confusing, don't worry — I'll explain in more detail later). The USI and Japanese proposals were subsequently combined to form the MIDI specification, and the first commercially available instrument to include MIDI (the Prophet 600) appeared in December 1982.

Communication

It's important to realise that MIDI is both a software and a hardware specification. The software protocol defines the MIDI 'instruction set' together with the data format and range for each instruction, whilst the hardware specification and associated communications protocol are responsible for transmitting and receiving MIDI information. We'll start off by looking at the communication aspect, but if hardware isn't your thing then feel free to skip to the next section - after all, it's an understanding of the actual MIDI instructions set and associated data structures which will give you the best idea of what MIDI can and cannot do for you.

The first thing to appreciate is that MIDI is a serial interface. What this means is that data is sent along the MIDI cable in 'single file' rather than in parallel 'chunks'. Parallel is faster than serial, as you might have guessed, but the decision to go serial was taken quite early on for reasons of simplicity and economy. Despite initial disagreements over the workability of MIDI on the grounds of its relatively slow transmission speed (Oberheim and Rhodes initially continued to work on their own proprietary parallel interfaces, for instance), it is these twin virtues which won through in the end.

The interface operates at 31.25 kBaud +/-1% (which is actually fast for serial transmission - compare it with RS232's 19.2 kBaud) and is asynchronous with a start bit, eight data bits and a stop bit; transmission of a single byte thus takes 320 microseconds. In case you're wondering, 'asynchronous' means that data isn't required to be received at fixed time intervals.

One advantage that serial transmission has over parallel is that the former isn't subject to the data skew troubles that arise when data is transmitted in parallel fashion over any more than a short distance. MIDI cables can have a maximum length of 50 feet (15 meters), which should be quite enough to meet anyone's demands.

Even if you know nothing about how MIDI works, you're probably familiar with the merry trio or duo of 5-pin DIN sockets that nowadays grace the rear panel of every synth, drum machine etc. There are three types of conector, as you probably all know: MIDI In, MIDI Out and MIDI Thru. The latter's function is to provide a direct copy of data coming in on MIDI In, the idea being that you can 'daisy chain' several items of MIDI equipment together - though as we shall see shortly, daisy-chaining is not a popular way of doing things.

What you may not know is that XLR connectors are also acceptable 'providing manufacturers using them make available all necessary conversion cables'. Three-pin XLRs are, of course, more costly than good ol' DINs, so you won't see them around much. Offhand, I can only think of Octave-Plateau who use them on the Voyetra Eight.

"No one will pretend that there aren't any problems, but these are details."

(Click image for higher resolution version)

Figure 1 gives the circuit diagram for the interface hardware as it appears in the MIDI 1.0 spec. The first thing you may well notice is that MIDI Thru is the same as MIDI Out - this is hardly surprising, because basically MIDI Thru is just a MIDI Out which takes its data from MIDI In rather than from the keyboard. As you'll probably also notice, the circuitry has been kept fairly simple, making it inexpensive to implement. It obviously wouldn't make much sense (even from the manufacturer's point of view) to have an interface which added exorbitant numbers of pennies to every piece of MIDI equipment that you bought.

The circuit is a five milli-amp current loop type, and the line is set at +5 volts when no data is being sent. The beginning of a transmission is signalled by the line going low (0 volts) for a one bit period; this is the start bit. One and a half bit periods and then seven bit periods are counted by the receiver, after which it expects to see a high level for one bit period; this is the stop bit. If the receiver doesn't see this then the byte of MIDI data isn't framed properly: if you've ever encountered a 'MIDI framing error' message, this is what it means.

At the receiving end of MIDI (MIDI In) you'll notice a component called an 'opto-isolator'. This has been included to eliminate ground loops from the system, as these can introduce an audible hum at the mains frequency (50 Hz) which is not exactly what you want from a music interface. The opto-isolator isolates (how did you guess) the transmitting and receiving devices by allowing an incoming signal to power an internal LED which in turn illuminates a photo-transistor which allows current to pass through when light falls on it. Thus there is no actual electrical connection between transmitter and receiver. The MIDI spec specifies that the opto-isolator should require less than 5mA of current to turn on the LED, and the rise and fall times at the output should be less than two microseconds.

It's here that the objections to the aforementioned daisy-chaining come in, because linking instruments in a sequential fashion means that several MIDI Ins will be connected and therefore the rise and fall times will add up to more readily introduce noticeable delays. Increasingly preferred is the star network, in which each instrument 'branches out' from a central 'axis'. At its simplest, this would be a multiple Thru box such as is manufactured by Roland, Korg and Yamaha. With this layout, additive rise/fall times are minimised. The potential for users to reconfigure their MIDI set-up is also enhanced, but that's another story.

If you stare at the circuit diagram again, you may well see the enigmatic legends 'To UART' and 'From UART'. UART is short for Universal Asynchronous Receiver Transmitter, and if that leaves you none the wiser I'll explain some more. As has already been noted, MIDI is a serial interface. But microprocessor-based systems (and all today's instruments are microprocessor-based, in case you didn't already know) move data around in parallel fashion, so obviously there needs to be some device which will perform parallel to serial and serial to parallel conversions. Surprise surprise, this is where the UART comes in. UARTs are used to support the well known RS232 serial interface, so they're not exactly hard to come by, though not all UARTs can manage MIDI's 31.25 kBaud transmission speed. Two which can, however, are very common - the Z80 SIO (Serial Input/Output) and the Motorola 6850 ACIA (Asynchronous Communications Interface Adaptor). The latter is buss-compatible with the 6502 microprocessor, (and is to be found in the BBC B and Commodore 64 micros, incidentally).

The UART is kept very busy, because it has to be able to 'disassemble' parallel data and transmit it serially, at the same time as 'assembling' incoming serial data, stripping off the start and stop bits, and informing the controlling microprocessor system when data is ready or if there are any data errors (such as the framing error mentioned earlier). I bet you didn't know there was so much going on behind those little 5-pin DINs.

Opening Channels

And so on to the MIDI software protocol. MIDI implements two data types: Status and Data bytes. Status bytes have their most significant bit (ie. bit seven) set to one, while data bytes have their most significant bit set to zero. The function of the former is to identify a message type, whilst that of the latter is to convey the actual information. Thus Status bytes always come before data bytes, and in general have a fixed number of such bytes associated with them.

MIDI messages are divided into two main categories: Channel and System. Channel messages are those which are intended for certain units in a system (the system being your MIDI equipment setup), while System messages are (surprise surprise) intended for all units in a system. A 'channel' within the MIDI context is defined by a four bit number in the lower half of the status byte. Four bits can represent a number from 0-15, which translates into 16 channels of MIDI information. Thus a channel in the present context is a logical, not a physical, entity: channel data is assigned to a particular channel by virtue of the channel number attached to it.

There are two types of channel message: Voice and Mode. Voice messages convey the following information: note or notes on/off, attack and release velocities, polyphonic and channel after-touch, control changes (this relates to performance controllers such as the modulation wheel or the sustain pedal), program change and pitchbend; ie. all the data which affects the actual sound produced.

"...tape-based recording allows you to transcend the limitations of an instrument, MIDI always pulls you back into those limitations. The ideal, then, lies in some combination of the two."

Mode messages define how a receiving instrument will allocate the incoming voice data to its own internal voices. There are four modes, respectively Omni on/Poly, Omni on/Mono, Omni off/Poly and Omni off/Mono. When Omni is on, voice messages are received on all of the 16 channels; when off, voice messages are received on the currently assigned channel only. When Poly is chosen, incoming data is assigned polyphonically to the instrument's voices. With Mono, assignment depends on whether Omni is on or off. If on, then incoming voice data from all channels will be assigned to a single internal voice; if off, then the internal voices are assigned one to each adjacent MIDI channel from the current basic channel up. Omni off/Mono thus allows for multi-timbral playing of incoming voice data.

All Systems Go

System messages are divided into three categories: Real Time, Common and Exclusive. Real Time messages are for synchronising all of the system in (you guessed it) real time. They can be sent at any time, which means that they can appear 'in between' any other message which consists of two or more bytes: needless to say, they interrupt rather than alter the current status.

Real Time messages are single byte (status byte, no data), and consist of a timing clock code which is sent at a rate of 24 clocks per quarter note (this is used by MIDI drum machines and sequencers), start, stop and continue codes (again, used by drum machines and sequencers), active sensing and system reset. The last facility is pretty self-explanatory - when sent, all receiving instruments will reset themselves to their normal waiting state.

Active sensing is an optional 'safety check' facility. An active sensing code is sent every 300mS (maximum) whenever there is no other activity on MIDI. Once a MIDI instrument with active sensing ability receives an active sensing code, it will expect to continue receiving such codes - if a period of 300mS passes with no activity on this front, the receiver will turn off all its voices and resume normal operation. What this means in practice is that if you've got two or more MIDI instruments hooked up, if a MIDI cable becomes disconnected for some reason then you won't be left with droning notes on a synth which hasn't received all the necessary note off codes.

System Common messages consist of a song select code and a song position pointer (the latter used by the Continue facility), a tune request (this requests analogue MIDI synthesisers to tune their oscillators) and the EOX (End of System Exclusive) flag.

System Exclusive is a very important area of MIDI because it's the one area which gives manufacturers the opportunity to deal with elements specific to their own equipment. Each manufacturer is assigned their own ID number, and this is used after the System Exclusive code to indicate that the following data (prior to the End Of Exclusive code) is specific to that manufacturer. Following the manufacturer ID each manufacturer can include an instrument ID as well. Following this, each manufacturer can determine their own data format, which should be published as part of the instrument's spec. The only restriction is that no bytes should have bit seven set (ie. they mustn't be Status bytes). This is because Real Time codes (which are all Status bytes) can be interleaved with Exclusive data; EOX or any other status byte will terminate System Exclusive.

Although the potential applications of System Exclusive are wide, its common use is to provide a data format for patch data which can then be transferred via MIDI (to a computer running patch dump software, normally).

Sequencing

Finally, as H&SR is a recording magazine, it seems reasonable to include a few words on MIDI-based recording, though what follows is in no way intended as a detailed consideration of the subject.

As you probably know, sequencing refers to the 'recording' of performance data for subsequent playback. In essence this is the same as recording onto tape, except that in the present case the recording medium is digital memory (RAM) rather than magnetic tape, and it's not analogue audio data that's recorded but digital MIDI data. Thus when you play Middle C, for instance, the data that's transmitted over MIDI is the Note On code, the value 60 (which means 'this pitch is Middle C') and an attack velocity value (a value of 64 indicates no velocity). Thus playing a note generates just three bytes. Obviously if these three bytes are stored in RAM, along with the requisite timing information and the matching Note Off data, and read back to your synth over MIDI, the note you played will be 'recreated', and this is just what a MIDI sequencer does. It stores all the details of your performance as they are conveyed over MIDI, and subsequently play that performance back to you. In many ways, the flexibility that the system affords is far greater than conventional tape-based recording, because of the extensive and very specific editing that you can carry out on the recorded MIDI data, and of course data stored in digital memory is not subject to the s/n generation loss that you get with audio tape. From a recording point of view, though, because a MIDI sequencer requires an instrument to replay its music data, that instrument is effectively 'tied up'. Whereas tape-based recording allows you to transcend the limitations of an instrument, MIDI always pulls you back into those limitations. The ideal, then, lies in some combination of the two.

Conclusions

The great benefit of MIDI is that it provides a standard communication protocol to enable digitally-based musical instruments to communicate with one another. This means that equipment made by different manufacturers is assured of compatibility, and musicians can pick and choose the equipment they want and configure the particular set-up they want without fear of finding that their various items of equipment won't work together. No one will pretend that there aren't any problems, but these are details. In all essential respects, one piece of MIDI equipment will function with any other piece of MIDI equipment, and that can only be good news both for musicians and for the manufacturers.