Home -> Magazines -> Issues -> Articles in this issue -> View
Talking MIDI (Part 4) | |
Article from Sound On Sound, March 1986 |
Jay Chapman delves deep into the murky waters of MIDI's often ignored Mono Mode in pursuit of multi-timbral expression!
So far in this series we have had an overview of what MIDI can presently, and might in the future, do for you: a look at the hardware used to transmit information around our MIDI network; a lengthy discussion of how such information is represented inside the world of computers; and we have invented our own protocol to give us some understanding of what sort of thoughts went through the minds of the guys who invented MIDI in the first place.
This month, we should be in a position to dive into discussing the real MIDI protocol without having to digress into the whys, wherefores and workings of bits, bytes, hexadecimal digits, etc, since you are now all experts (stop laughing hysterically that man on the back row!). If you are not expert then consider this paragraph to be a plug for the SOS back issues department...
We'll start the ball rolling by seeing how MIDI solves one of the major problems that our own protocol fouled up on. In general, we need to know unambiguously what element of the protocol each byte is supposed to be representing. In particular we would like to recognise each status byte as it arrives. One problem we can have occurs when a byte gets corrupted or lost during transmission, so that we don't know where we are (ie. we lose our place) in the incoming byte stream. If the next correctly received byte has a bit pattern that could form a legal status byte, and equally well could be a data byte for a previous status byte, then we have no way of telling which it is! What do we do - yell "help"?!
The general problem of a lost or corrupted byte is unsolvable in MIDI - once a byte is lost it will never be found again for example. Various synthesizer manufacturers have made attempts to try to do something sensible in these circumstances and I'll mention some of these in a future article. What the MIDI protocol tries to help implementors do in such cases, is to attempt to minimise the damage (musically!) done by the missing byte. The point here is that we don't know where we are in the MIDI byte stream so it would be nice for MIDI to give us a marker every now and again to say something like 'you are now at a known point - start interpreting the bytes again'.
The 'known point' we need is provided by MIDI by telling us, for every byte transmitted around the network, whether it is a status or a data byte. This is done by having the leftmost bit (bit 7, the sign bit) set to 1 in a status byte and reset to 0 in a nonstatus, or data, byte. Thus a status byte will be of the form %1xxxxxxx and a data byte will be of the form %0xxxxxxx where x indicates a bit value that could be 0 or 1.
If a byte is corrupted then the receiver could stop interpreting bytes until a byte with its leftmost bit set to 1 arrives. The receiver now knows that it has a status byte and will (in most cases) know how to continue correctly. This is a slight simplification of the situation but will serve for this discussion. As an example of what could happen, consider a stream of (non-running status) keyboard on and off messages such as:
[KEY ON] [middle C] [medium velocity] [KEY OFF] [middle C] [fast velocity]
I've used words rather than the actual numbers for ease of understanding! The actual bytes (over MIDI channel 1 - see later) would look something like:
[&90] [&3C] [&40] [&80] [&3C] [&60]
Now, the key on and key off messages (whose MIDI protocol details will be considered later) are each announced by their respective status bytes shown as KEY ON and KEY OFF above.
Let us assume that one of the data bytes, say the one giving the number of the note to be turned on (ie. the 'middle C' byte), gets corrupted. The byte stream now looks like this:
[KEY ON] [********] [medium velocity] [KEY OFF] [middle C] [fast velocity]
If the MIDI receiver knows that the byte shown above as asterisks is corrupted, then it may well decide to ignore all bytes until the next status byte arrives. When the KEY OFF arrives the receiver is able to start work again. It will then try to turn off a note which it hasn't yet turned on which usually won't cause any problems. However, if it is a KEY OFF message that gets ignored in this way, we may well end up in an ongoing drone note situation!
It is possible, however, for a receiver not to have any idea at all that a byte was corrupted or lost (especially if the guy who wrote the receiver's software is not too competent!) in which case the message bytes would look like this:
[KEY ON] [medium velocity] [KEY OFF] [middle C] [fast velocity]
Since the KEY ON byte would have its leftmost bit on (1), the receiver knows it has a status byte and can confidently recognise it as a KEY ON. The next byte should be the key number and should, of course, be a data byte and have its leftmost bit off (0). Well, the medium velocity byte does have that bit set to 0 (since it is a data byte) and the receiver therefore merrily decides that the medium velocity byte is, in fact, the key number... The next byte received is the KEY OFF byte which has its leftmost bit on and the receiver software (if well written!) should be highly suspicious at this point!
The receiver knows that something has gone wrong. Since the KEY ON message is incomplete the receiver shouldn't actually perform the key on function and will probably indicate something like 'MIDI Error!!!' on its display which will no doubt make you give birth to half a dozen or more kittens if you happen to be in the middle of auditioning for the latest offshoot from Duran Duran...
If the receiver was going to ignore (what it thought was) the velocity byte anyway, because it can't cope with keyboard velocity, it may decide it has sufficient information to execute the key on since it thinks it has the key number OK. If you often get the E above middle C acting like a bagpipe drone that's because it is note number 64 and velocity value 64 is what non velocity sensitive MIDI keyboards send out as the default velocity in KEY ON messages! To be fair to MIDI, you will hardly ever get such errors provided your equipment sticks to the MIDI Specification. If your mad keyboard player uses his MIDI cables as the target during his ethnic knife throwing solo, don't blame me for MIDI errors though!
We'll come back to this subject (losing MIDI bytes - not knife throwing!) when we discuss running status in later articles. For now you can note that we can tell status and data bytes apart very easily by looking at the leftmost bit. Since all status bytes are of the form %1xxxxxxx, the lefthand nybble is of the form %1xxx and is therefore one of the hexadecimal digits &8 (%1000), &9 (%1001), &A (%1010), &B (%1011), &C (%1100), &D (%1101), &E (%1110) or &F (%1111). This digit tells us what sort of message we are sending or receiving whilst the righthand four bits of a status byte tell us which MIDI channel we are playing with (except in the &F case which we'll deal with in due time).
As we saw last month, we need to be able to tell the various receivers in our MIDI system which messages they need to respond to. In the simple case of one synthesizer controlling another (with no keyboard splits or multi-timbral facilities in evidence) we connect the transmitter's MIDI Out to the receiver's MIDI In and there need be no confusion.
If there is going to be more than one receiver (or even more than one transmitter!) we need to identify who responds to what. This is where the righthand four bits in all (but the &F type) status bytes comes in. Four bits gives us 16 possible values which is why MIDI has 16 channels available. The 16 values in binary are %0000, %0001, %0010... %1111, which we all know correspond to the decimal numbers 0 to 15. However, most musicians count from 1 and not 0, so the 16 channels are numbered channels 1-16 on the synthesizer's display but 0-15 internally!
You maybe wondering how the simple transmitter/receiver case described in the first paragraph of this section can work since I didn't specify any channel selection for either transmitter or receiver... read on!
There are four MIDI Channel Modes which are formed from the combinations of three states your MIDI equipment can be in (OMNI, POLY and MONO). The POLY and MONO states are mutually exclusive ie. if you are in POLY mode you are automatically not in MONO mode and vice versa. The four modes are as follows:
Mode Mode Messages
1 OMNI On; POLY
2 OMNI On; MONO
3 OMNI Off; POLY
4 OMNI Off; MONO
As you can see, we have the possibility of OMNI being On or Off and in either case we can be in either POLY or MONO mode. This naming is a little confusing at times so we'll consider the possible states separately and then in combination, firstly, for the MIDI receivers.
This is an easy one to understand! If you have OMNI On in a receiver then it won't even look to see what the channel number is in the status byte of a message; it will always respond to the message! When you power up your MIDI receiver (synthesizer, expander, whatever) it will come up in the OMNI On state and so you don't need to set its (receive) channel or the controlling device's (transmit) channel for the latter to drive the former. This is a clever bit of design by the MIDI men since a musician new to MIDI can be confident that if he/she manages to connect one synth's Out to another's In, something will happen!
OMNI Off means that the receiver should only respond to any messages whose MIDI status byte contains the correct channel number. Simplifying for a moment (see MONO later), we should be able to set the receiver's MIDI channel number on its front panel. Note that all of the receivers who are on the same MIDI 'daisy chain' (via their In and Thru connections as we discussed in previous articles) will all listen to all of the messages coming down the 'daisy chain'. In OMNI Off state they will merely not respond to a particular message unless its channel nybble corresponds to their own receive channel setting. In any software you write, don't forget that a front panel setting of 'receive channel = 16' will equate to a MIDI status byte channel nybble of %1111 (or 15)!
Back to sanity. To be accurate, both your MIDI receivers and transmitters actually power up into Mode 1 as described in the table above. This mode not only consists of OMNI On but also POLY, so let's look at what POLY means.
No prizes for guessing this one! All key on and key off messages that arrive at the receiver on ANY channel (in OMNI On), or all such messages that arrive on the specified channel (OMNI Off) will be responded to within the voicing capability of the receiver. So, if your receiver is a Yamaha DX7 or TX7 which can handle 16-voice polyphony, you can throw 16 key on messages at it and end up with a 16-voice chord playing. Would you believe that an Oberheim Matrix-6 will handle a 6-voice chord in POLY mode because it has (effectively) six sets of voice generation 'circuitry'.
The transmitting keyboard has the very simple job of sending out all channel-based messages over the selected, single transmission channel which should be the same as that of the intended receiver, of course! There is the odd synthesizer in the world which won't let you select this transmission channel (the DX7) and leaves you on MIDI channel 1 forever, which is a pity... Note that it doesn't matter whether the transmitter is in OMNI On or Off, the transmission is still just over the single selected channel.
Since you're obviously an intelligent and observant reader - I can tell this because a) you read SOS, and b) you're reading this article (well, you've read this far anyway) - you're probably thinking that the next section heading will be MONO. Well, MONO mode is a bit more complicated than one might expect so I'll build up to it gradually via a spot of apparent digression.
Even those of you who have owned polyphonic synthesizers for some time may well have never considered how the chords and runs you play on a keyboard actually get assigned to the voice circuitry - in other words, which voice plays which note in the chord. Consider for a moment what happens when you play a seventh note whilst still holding down a 6-note chord that you have already played on your 6-voice synth. What choices has the synthesizer got?
Well, the first choice is to ignore the new note completely. If the new note is part of your sweetly moving melody cascading into the future (eh?) then the amazing lack of the new note will stand out like a sore thumb and you won't be too impressed - so most synthesizers will play the new note! What will happen is that one of the current voices will be stolen from the chord to play the new note. If you keep adding more new notes then more of the old ones will be stolen to deal with them! Since heavy metal synth players (a contradiction in terms?) can't move more than two fingers on each hand at the same time, they don't face this problem. (That was a joke Mr Lemmy, sir. Would you please take my head out of your vice...)
Having decided that we will steal a voice and re-assign it, which voice do we steal? Well, we could take the voice playing the highest pitch, or the lowest, or perhaps the voice that was assigned furthest in the past - now there's a good idea! The Oberheim Xpander even has a mode where if the note played is one that is already playing, the voice re-assigned is the one currently playing the note in question. That's not as daft as it sounds, some synthesizers will keep assigning voices until all are playing the same note!
Turning again to the Xpander, there is a mode where the lowest numbered unused voice of the six is always assigned even if there are other voices free. This might seem unnecessary but you have to remember that Oberheim's Xpander is a multi-timbral synthesizer and it would be quite possible to assign one program sound to voice number 1 and a different program sound to the other 5 voices. If you now play monophonically (no legato!) you hear voice 1's program sound only. If you hold a note and then play up to a 5-note chord, you will hear the chord played in the second program's sound without using any keyboard splits!
In more normal circumstances one would expect a multi-timbral synthesizer to take advantage of keyboard splits (or zones, or doubling, or whatever!) to tell the sets of voices using different timbres, what to play. As a simple example, we might split a five octave keyboard into three zones of one octave, two octaves and two octaves from the lower to the upper end. We then assign one of our six voices to the lower octave and select a program sounding like a bass guitar, say. The middle two octaves are assigned four voices all with the same organ-like program. The top two octaves will be assigned the last of our six voices set to a flute program for the solo work. Lastly, we make the four organ program voices take notice of the sustain pedal so that we can play solo flute over sustained organ chords with a contrapuntal bass!
But what do we need to do so that the right voices get assigned to the right part of the keyboard and the different messages all get from/to the right places?
Okay, I'll tell you the truth: it's nowhere near as difficult as it sounds - provided you understand what roles the expander and the keyboard controller are playing! Let's take things one small step at a time...
In Figure 3 the three keyboards have been merged (Superglue's marvellous stuff!) as have the three expanders but the six control flows (1-4-1) are still shown as dotted lines to the 6 voices. If we think of this as ONE instrument (with the unused voices from each of the original three synths thrown away), we have just constructed (one configuration of) the Oberheim Xpander controlled by sort of pseudo-CVs from a suitable keyboard!
If we want MIDI to handle this communication between a (split) keyboard and a (multi-timbral) expander, all we have to do is get the six control flows safely between the keyboard and the expander. Note that if I consider these control flows at the point marked "LINE" on the diagram, I don't have to worry about the keyboard's split details (handled by the keyboard circuitry) or about the expander's voice assignment (provided the expander knows that control flow 1 is the bass, 6 is the flute and 2 to 4 are the organ).
Now I could arrange for 6 separate MIDI links (6 Outs on the keyboard, 6 cables, 6 Ins on the expander and possibly 6 Thrus as well) but that would be expensive and wasteful. After all, I've got 16 channels available using MIDI so why not use a separate channel for each control flow! This is shown in Figure 4 where all 6 control flows merge into one MIDI connection. At the expander end, the 6 control flows are separated and sent to the relevant voice circuit according to their MIDI channel numbers. We now know enough to describe MONO mode!
The discussion above relates to MIDI Channel Mode 4 which is OMNI Off with MONO. In this mode the controller (be it keyboard, computer or whatever) will be told what splits it should implement and how many MIDI channels (or control flows) are to be used. The controller will also have a transmission channel number selected in the normal manner.
The receiver will have to be set to MIDI Channel Mode 4 also and be told to respond to the same set of channels, one per voice. It might seem wasteful to have four channels used up by the organ voices, since they are all the same timbre and could have been transmitted as one (polyphonic) channel with the expander's normal voice allocation system sorting out the polyphony. The difficulty here would have been the complexity introduced in coping with the fact that, even with just six voices, there are quite a few combinations of voices and splits that we might want to specify eg. 1-5, 2-4, 3-3, 1-1-4, 1-2-3, 1-1-1-3, 1-1-2-2, etc. Imagine trying to preset all the possibilities on a 16-voice multi-timbral synthesizer!
In MIDI Channel Mode 2, where we have MONO with OMNI On, there is only one voice assigned, which is therefore automatically only capable of playing monophonically, to all messages coming in on any of the 16 channels. Note that true legato playing is possible in MONO mode, since playing a second note while a first is still held will normally result in the second note being assigned the single voice available and therefore the first note stops at exactly the moment the second note is played.
I have already mentioned that MIDI devices normally power up in Channel Mode 1 and, in fact, they will stay in this mode until told explicitly to do otherwise. A change of mode might be directed from the device's front panel or may come from a controlling device over MIDI. There are four channel mode messages which force a change of status to OMNI On, OMNI Off, MONO or POLY. These messages form part of the set of Controller messages and will be detailed in a later article.
I hope the recognition of status bytes and particularly the use of MIDI channels now seem a bit less mysterious. Even if you never intend writing a single computer instruction during your involvement with MIDI, I'm sure all this brainwork will help you to take fuller advantage of your current MIDI set-up. When some money for expansion becomes available (1999?) the technicalities of a growing MIDI network will hopefully be less likely to cause confusion and you'll be able to make some sense of the salesman's jargon!
By the way, don't be fooled into ignoring the delights of the apparently complicated OMNI Off;MONO mode or even pretend it doesn't apply to you simply because expensive DX7s and Oberheim Xpanders were used as examples of 16-note polyphony and multi-timbral capabilities respectively - the humble Casio CZ-101 can also demonstrate how worthwhile this aspect of MIDI is! Have fun!
Read the next part in this series:
Talking MIDI (Part 5)
(SOS May 86)
All parts in this series:
Part 1 | Part 2 | Part 3 | Part 4 (Viewing) | Part 5 | Part 6 | Part 7 | Part 8
Mixing Essentials - Mixing in the MIDI Age (Part 1) |
MIDI Basics (Part 1) |
![]() |
MIDI Muting - Sound Workshop |
Effective Automation - Creative mixing with MIDI controlled effects (Part 1) |
![]() The Myths Of MIDI |
MIDI - An Introduction |
![]() Sound Bites - Production Tips & Techniques |
Climb Aboard The MIDI Bus (Part 1) |
Technically Speaking |
MIDI Theory and Practice |
Why MIDI Music Stinks - (Sometimes) |
Browse by Topic:
Topic:
Series:
Part 1 | Part 2 | Part 3 | Part 4 (Viewing) | Part 5 | Part 6 | Part 7 | Part 8
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!
New issues that have been donated or scanned for us this month.
All donations and support are gratefully appreciated - thank you.
Do you have any of these magazine issues?
If so, and you can donate, lend or scan them to help complete our archive, please get in touch via the Contribute page - thanks!