MIDI Matters (Part 2)
Back To Basics
Jay Chapman continues his 'back to basics' description of the technicalities of the Musical Instrument Digital Interface for the many new readers who have picked up on the series since it first began.
This month 'Back To Basics' concentrates on the types of MIDI messages that are available. In particular, we look at messages in terms of how receiving devices in a MIDI network are specified. In other words, how do we know which device a message is intended for? After all, in the analogue days of control voltages and triggers you could see the pieces of wire trailing between connected instruments... it's not quite so simple where MIDI is concerned.
We will also start to look at what Time means in a MIDI system.
However, just before we continue our trip through MIDI Basics, I should point out that a little error sneaked into last month's article. The MIDI Note Numbers run from 0 to 127 giving a 10 octave range and not 12½ as I said. Of course, this was just me testing to see if you were awake. Ah well... let's get down to the nitty-gritty and start off with something really useful.
One of the central ideas of MIDI involves getting information from a transmitting device (eg. a keyboard, or a sequencer in playback mode) to a receiving device (eg. a synthesizer module, or a sequencer that is in record mode). Now if we only had two devices in total, this set-up would present very few problems - just connect the transmitter to the receiver (MIDI Out on the keyboard to MIDI In on the sequencer, say) and away we go. In fact, this is exactly what MIDI tries to do for you in this situation, as we shall see when we look at Channel Modes in a later article.
If we have more than two MIDI devices (typically, one transmitter and many receivers) life becomes a little more complicated.
Our problem is that when we try to control several receiving devices we need to be able to specify which piece of control information is intended for which receiving device. Consider the following dubious analogy concerning two different lighting systems.
In each room of a (simply wired) house, there is a light in the centre of the ceiling and a light switch by the door.
To control the light you switch on/off its light switch, ie. there is one switch per light and each switch connects directly to, and controls, exactly one light. In other words, each receiver (light) knows which transmitter (switch) to take notice of. On the other hand, typical Christmas tree lights (the receivers) all light up or go off together when the single switch (the transmitter in our analogy) is turned on or off.
To be fair, this analogy isn't too clever but it illustrates the point. In these two examples it is the wiring that determines whether a specific receiver can recognise a specific transmitter; in the case of the tree lights, no receiver can ignore the commands of the single light switch, for example. We could put a transmitter (switch) in the circuit for each of the tree lights but all the lights would be affected when any switch on or off - not a lot of use! MIDI is more like the tree lights than the room lights (electrically at least) in the sense that all messages are sent to all receiving devices. In fact, unless we put a MIDI filtering device in the way (more of which in a later article), MIDI behaves rather like Radio 1 in that it is a broadcast system. All messages are sent to all devices and all devices are expected to be listening - it is up to each individual receiver to decide whether a message is to be taken notice of or not.
Let's set up an example situation. We have a master keyboard controlling two expander modules. The keyboard is clever enough to perform a split so that the left-hand side of the keyboard is to control one of the modules, the right-hand side the other. So, we have one transmitting device that needs to be recognisable as two separate controllers or transmitters. Since MIDI cables connect to all devices, we will need some information held in the messages themselves to specify which device (or part of a device) the message came from and this is where the idea of a MIDI Channel comes from.
As we already know, each MIDI message is recognised by its Status byte which says whether it is a Note On, a Program Change, a Pitch Wheel bend or whatever. The Status byte also carries, where appropriate, a number that specifies the MIDI Channel. This Channel number is in the range 1 to 16.
In our above example, if we make the left keyboard split send messages with Channel number 14 (say) in its Status byte and the right keyboard split send messages with Channel 3 (say) in its Status bytes, we have solved half of the problem (the 'transmitting' half). We will probably have to press some buttons on the front of our master keyboard to set up the split; at this point we will also set up the transmit channels for each of the keyboard splits we have specified.
The second half of our problem (the 'receiving' half) is solved by selecting the correct receive channels on each of our expander modules. The expander which is to respond to the notes in the left split needs setting to receive on Channel 14, the right split on Channel 3. As each Status byte arrives the receiver checks to see if the Channel number contained in it matches up with its own 'receive channel' number. If it does, the receiving device pays attention to the message and does what the message tells it. If not, the message is ignored.
There are two main categories of MIDI messages: those that contain Channel information and those that don't! These are known respectively as Channel and System messages.
Channel Messages have been explained above. In general, if a given receiver is expected to only act on messages specifically intended for it (although the message stream may contain messages which are not for that particular receiver), then Channel messages are used (there is another, more esoteric, way using System Exclusive messages but we'll come back to that at some other time). Channel messages are split into two types: Channel Voice messages and Channel Mode messages (see future articles).
System Messages are for all receivers in the system to act upon if they can and, therefore, they do not contain a Channel number. As we shall see, receivers may ignore this type of message for various reasons, eg. if they can't do what the message asks or perhaps they can't understand the message at all! There are three types of System message: Common, Real-Time, and Exclusive.
Common Messages are general messages for all units on the system. One of these is Tune Request, which is a plea for any analogue synthesizers connected to the system to tune their oscillators. Another Common message is the End-of-System Exclusive message, which is really out of place here and will be dealt with when we explore System Exclusive messages in a later article. Finally, there are the Song Select and Song Position Pointer messages which will be dealt with once we have figured out MIDI's concept of time! (What an amazing cop-out of a paragraph!)
Real-Time Messages are rather special. They are intended for all devices in a MIDI system. All Real-Time messages consist of exactly one byte - their Status byte; in other words they never have any Data bytes. It is interesting to note that they can appear absolutely anywhere in the MIDI message stream - even in the middle of other messages! The reason these bytes get such special treatment is that they need to preserve their Real-Time characteristics. To understand this we need to be sure we know what Time itself means to a MIDI system.
Time is time, Jim, but not as we know it... In fact, in a lot of cases, we don't need to explicitly know anything at all about time in our MIDI system. For example, when somebody plays a note on our master keyboard a Note On message is sent to all the connected MIDI devices, which then deal with it as they see fit. The time implied by the message means quite simply 'this note was played now'. And ignoring tiny delays in the system (which are generally far too short for us to notice anyway), the note is effectively transmitted and received 'now' and will be heard 'now' as well!
However, if we have a sequencer set to some particular playback tempo, it can send out Note On (and other) messages at appropriate times according to its own internal clock and it, therefore, defines what time currently means. Although 'normal' time doesn't vary (give or take Special Relativity according to Einstein), if you set the sequencer to a faster or slower tempo than the song was recorded at then the relative timing of the messages will change. If you have a drum machine playing along with the sequencer, it needs to work to the same version of time as that which the sequencer is defining. In short, the two devices need some means of achieving synchronisation.
MIDI Timing Clock
Time, in the real world, is a continuous flow but in the MIDI world it is a series of steps, or clock 'ticks', which any device interested in time can watch out for and count. If a drum machine is told to sound two drums at an interval of one crotchet apart, it would sound the first drum and then count ticks coming from the sequencer and play the second drum when it has counted the correct number of ticks. Where MIDI is concerned there are always 24 Timing Clocks (or 'ticks') to a crotchet, so the drum machine would count up to 24 and then sound the second drum.
In this way, it doesn't matter if you decide to slow down (or speed up) the tempo of the sequencer since the drum machine will still count the same number of Timing Clocks, they will simply arrive more slowly (or more quickly) than before. Now if Timing Clocks were unduly delayed (whilst waiting for a current multi-byte message to clear out, for example), then a Timing Clock might arrive late and the events that should have occurred at its intended arrival time would be 'out-of-time', ie. their Real-Time characteristics would have been lost.
Now that we have Timing Clocks on board we can proceed to the rest of MIDI's Real-Time messages. Don't miss the next thrilling instalment of 'Back To Basics'!
Feature by Jay Chapman
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!