Talking MIDI (Part 5)
Part 5 sees software specialist Jay Chapman exploring the innermost secrets of 'channel voice messages' and more in his continuing analysis of the MIDI protocol.
Jay Chapman returns from his short break, batteries recharged, to deliver the fifth instalment of his series on the bits and bytes of MIDI.
This month's epistle continues our quest for the inner secrets of the MIDI protocol. In Part 4 we sorted out the concepts of status bytes, MIDI channels and MIDI channel modes so we should now know how to tell where the start of a message is, which of sixteen possible listeners should take notice of the message, and also how the internal voice assignments are selected on a synthesizer.
We now move on to consider specific message types which fall into two main categories: channel and system. As you might well guess, the channel type messages include the MIDI channel number in the least significant nybble of the status byte as we discussed last time. These messages therefore convey control information which is not intended for all devices in our MIDI network; examples would be a program change for a specific synthesizer or perhaps a series of note on and note off messages for the synthesizer playing the bass line only.
The system message types deal with information which every device on the network may well be interested in such as timing information for synchronisation purposes. If these messages could not be sent out in some manner independent of the MIDI channel mechanism we would have to send each message sixteen times (on channel 1; then channel 2; then ...) to be sure that every device had taken notice of the message. This would obviously be a waste of time and effort. We will look closely at system type messages next month.
Channel type messages fall neatly into two logical categories: voice and mode type messages. The mode type messages correspond to the MIDI channel modes that were discussed last month. These messages, which are tucked away at one end of the control change messages as we shall see later, tell a receiving device to change mode (to something like OMNI Off; MONO for example) provided it is on the channel specified in the status byte. We'll explore the details later in this article.
With the MIDI facilities discussed so far we can set up our MIDI network, get the devices into the correct MIDI channel modes and listening on the correct MIDI channels. Most of the time what we want to communicate in this situation is performance control information ie. that a specified synthesizer, or even a particular voice within a synthesizer, will play certain notes, do a pitch-bend at a specified point, and maybe change to a new program at some other point in time. We use channel voice type messages to send such control information.
The channel voice messages are listed in Table 1.
Table 1. Channel Voice Message Status Bytes.
|Status Byte (%nnnn = channel)||Number of Data Bytes||Description of Channel Voice Message|
|%1000nnnn||2||Note Off event|
|%1001nnnn||2||Note On event|
|%1010nnnn||2||Polyphonic Key Pressure|
|%1110nnnn||2||Pitch Wheel Change|
|Status||Data 1||Data 2||Description of Data Bytes|
|%kkkkkkk = (key) note number|
|%vvvvvvv = key velocity|
|%kkkkkkk = (key) note number|
|%vwww = key velocity|
|%1010nnnn||%0kkkkkkk||%0ppppppp||Polyphonic Key Pressure|
|%kkkkkkk = (key) note number|
|%ppppppp = key pressure|
|%ccccccc ^controller number|
|%vwww = controller value for values 0 to 121 (for 122 to 127 see Table 4)|
|%ppppppp = program number|
|%ppppppp = keyboard pressure|
|%1110nnnn||%0LLLLLLL||%0hhhhhhh||Pitch Wheel Change|
|%LLLLLLL = low order 7 bits|
|%hhhhhhh = high order 7 bits|
We start off with the channel voice messages used to turn notes on and off. The two messages, note on and note off, are obviously closely related - a few of the former without an exactly corresponding few of the latter could prove embarrassing! Note on/off control information is going to form the most common set of messages transmitted around the MIDI network.
We must include some identification of which note we want to turn on or off and the first data byte does just that by holding the number of the note in question (%kkkkkkk). Table 3 shows the correspondence between note names and note numbers (which was discussed in Talking MIDI Part 2). We have seven bits in each data byte at our disposal so with one data byte we can choose to represent numbers in the range 0 to 127, giving us a ten and a half octave range keyboard! Middle C is set near the mid-point of this range at key number 60 and other numbers represent a particular semitone measured up or down relative to this point.
Figure 1 shows the MIDI keyboard number range in the context of a piano and a DX7. It is worth making the point that most electronic instruments equipped with MIDI will actually be able to respond to note numbers outside the typical four or five octave range of the physical keyboards usually used to drive them. When a computer system or sequencer is used instead of a keyboard, or when a computer system or MIDI transpose effect unit is used to change the range of note numbers transmitted, it is possible to produce interesting effects from opposite ends of the note number range: for example, where key following (or Keyboard Level Scaling as it's called on a DX7) is employed.
Table 3. MIDI Note Names/Note Numbers.
|Note Name||MIDI Note Number|
You will probably have spotted that a velocity value of zero in a note on message is regarded as something special. This is not surprising in one sense since a velocity value of zero presumably means that you are pressing the key infinitely slowly and will therefore never finish! Since the message can't be sent until you finish, we would be part of a paradox if we ever transmitted this message! Enough of the philosophy...
In fact, if a note on message arrives with a velocity value of zero it is interpreted as a note off message. There are two very good, and related, reasons why MIDI specifies this. Firstly, since most of the devices in our MIDI network don't understand the key release velocity data found in the note off message, we would only be sending redundant data and therefore wasting time and effort (if we update our equipment and need this facility we can use it, however, since the note off message does exist). The second, and more important, reason has to do with running status which will be explained fully in a later article. For the moment it is sufficient to know that our MIDI system can save a lot of transmission time by not changing to a new status after every message. Since we can use note on messages for both notes coming on and for notes going off we can improve the efficiency of the system (see the 'Improving Efficiency' section in Talking MIDI Part 3).
This is a channel voice message type only for those keyboards in the megabuck class I'm afraid - well, at least for the moment! In a couple of years it may well be possible for the average musician to buy keyboard instruments with individual aftertouch sensors on every key. This would mean that by pressing harder on one or more notes of a chord it would be possible to apply some form of modulation to just that note's voice with the amount of pressure acting as a modulation parameter individually for each note. You might be adding vibrato to just the melody line note independently of the chords held on the same keyboard which you don't want vibrato added to, for instance.
The data for this message is dealt with in a similar manner to the note on and off messages in that a key number is transmitted as the first data byte. The second data byte contains a data value representing the pressure currently being applied to the key specified. If you vary the pressure then a new message will be sent out showing the new pressure value. In this way, if you continually vary the pressure then the transmission of messages will go on incessantly as your synthesizer strives to keep the rest of the MIDI network up to date on how much pressure you are applying to each of the keys you are holding down. Since holding a dead steady pressure is something that human beings don't excel at, it is possible that many unnecessary messages are sent and this can sometimes be bad news. We will come back to this point when MIDI sequencing is discussed in a future article.
This message type is arguably one of the most interesting of them all! Several different jobs are handled by this message type, some related and some not, and it is the major area where expansion is possible in terms of performance control. If MIDI doesn't have all the features that you want then this is where you have some freedom to add some bells and whistles of your own. The rest of the world probably won't understand them directly but that's not the problem it might seem to be at first glance. Manufacturers are becoming aware that they should build facilities into their instruments to interface with this section in a flexible manner, so all is not lost!
As you can see in Table 2, the control change messages contain two data bytes. In general the first data byte (%0ccccccc) specifies which controller, or which part of a controller, we are interested in, whilst the second data byte (%0vvvvvvv) says what value the controller is currently set at. Let's deal with this general case first.
MIDI only understands two forms of controller: either the controller is continuous, such as a modulation wheel or joystick, or it is an on/off switch such as the membrane keypads that appear on most synthesizer front panels these days.
The on/off switch only has two states which MIDI represents in the second data byte (%0vvvvvvv) of the control change message as either the value zero (% 0000000) or 127 (% 1111111). The controller numbers (%ccccccc), which appear in the first byte, are shared out amongst the various types of controller; the switches occupy controller numbers 64 to 95 which therefore allows for 32 switches in all - enough to keep most of us happy for a week or two at least!
The continuous controllers are organised in what appears to be a slightly strange manner for reasons of efficiency, and occupy controller numbers 0 through to 63 inclusive. It is actually possible to transmit information about 32 continuous controllers over MIDI so you can rightly conclude that two control change numbers are used for each continuous controller. Before I describe how these pairs are used I had better explain why a pair of controllers is required.
In Talking MIDI Part 3 (February 86 edition) I described how (in 'our own' version of MIDI) key velocity, which is in reality a continuous quantity, could be represented by a set of seven integer values, which are discrete quantities. Now the best MIDI can do in representing continuous data is to choose the nearest integer in some range (this is one of the inherent problems associated with analogue-to-digital conversion-and therefore sampling-which would need an article in itself to explain in detail!). In fact, if we take the standard MIDI data byte, %0ddddddd, then the range of values we have to play with is that given by the seven bits ie. 0 to 127.
If we mark out the range of movement of a controller (electronically!) into 128 sections and number the sections 0,1, ... 127, we can sense the current position of the controller relative to some reference point (such as the sensors doing the reading of the section numbers). We must check to see if the controller has been moved (or let it tell us automatically) and if it has, then we send out a message saying control change on this controller giving its new position as the section number now at the reference point. So, provided we notice changes often enough the effect produced will seem to be smooth and continuous provided the resolution given by taking 128 sections is sufficient for the task in hand.
To see how the resolution required matters, consider using a controller to pitch-bend a sound (the same principle also applies to the pitch-bend controller which has a channel voice message of its own - see later). If we limit ourselves to a maximum pitch-bend of two whole tones, then each of our 128 sections would represent a pitch change of 2/128ths or 1/64th of a whole tone. Since human beings can't perceive pitch changes of this order any pitch-bend via our controller will appear smooth and continuous. If, however, we have a hypothetical pitch-bend strip running the length of a five octave keyboard and intended to allow pitch-bend over that range, then we have problems. Our 128 sections taken together now cover a range of some 30 whole tones and so each of our 128 sections represents a pitch change of 30/128ths of a whole tone, equivalent almost to a quarter tone! This restriction to 128 sections means that our smooth pitch-bend suddenly turns into a glissando from the start note in 30/128ths of a tone steps - not quite what we intended!
All we need do to solve this problem is to use more sections on our controller ie. provide a finer resolution. If we could have, say, 3000 sections rather than 128 then our pitch-bend could be controlled in 30/3000ths (or 1/100th) of a whole tone steps and all would appear smooth and continuous again! But we only have 128 sections capable of being represented in our MIDI control change data byte, so what are we to do? Quite simply we use a second control change message, giving us another data byte, if a resolution finer than 1/128ths is required.
Our double message now gives us two data bytes which we form into one number. There are seven bits in each of the two bytes which we take to be the most significant and least significant seven bits of the same numeric quantity. So, if we have the two data bytes %0hhhhhhh and %0LLLLLLL giving the two numeric values h and L (each in the range 0 to 127), then the number formed overall is h x 128 + L giving a range of values from 0 to (127 x 128 + 127 =) 16,383. This is the range of numbers that the 14 data bits from the two bytes can represent when formed into the single number %hhhhhhhLLLLLLL. This means we can now go down to a resolution of 1/16,384th of whatever it is that the controller in question does!
Okay, we now know what we need to do: if we need a resolution that can be provided in seven bits or less we send only one continuous controller change message containing only one data byte; if we need between 8 and 14 bits of resolution then we have to send two messages to get all the bits across. The 64 controller numbers allocated for these continuous control change messages are split into two halves ie. controller numbers 0 to 31 and 32 to 63. The first half of the controller numbers (%ccccccc = 0 to 31) are used to transmit the most significant controller value data bits (%hhhhhhh) of continuous controllers 0 to 31; the second half (%ccccccc = 32 to 63) are used to transmit the least significant bits (%LLLLLLL).
Quite often we have no need to send a pair of messages but if they are both required the most significant byte would be sent first and then the least significant byte. As an example, consider the modulation wheel which MIDI defines as being controller number 1. This means that controller numbers 1 and 33 are allocated for the modulation wheel: 1 for the most significant byte and 33 for the least significant byte. We now have several possibilities. If the wheel is moved a very small amount then only the least significant byte might change so we only send one controller message with the controller number set to 33 showing the change by giving the new value of the least significant byte.
If the controller wheel moves more substantially and both the most and least significant bytes change, then we have to send control change messages for controller numbers 1 and 33 with one data byte each. Our last possibility is that we only generate (say) five bits of resolution for the modulation wheel in any case, so one data byte containing seven data bits is more than sufficient therefore we only send a controller number 1 message and don't bother with controller number 33.
We have now 'used up' controller numbers 0 through to 95 inclusive, so what are the rest used for? Well, 96 through to 121 inclusive are left completely undefined by the official MIDI specification! They can thus be whatever you fancy: continuous, switches, anything you can think of, in pairs, in groups of 6 (to get 6 x 7 = 42 bits worth of resolution!) - just use them for anything at all! Connect your light show up to MIDI and control the colour gels and the spotlight angles from a funky bass line - why not? The possibilites here will be explored in a future article.
The last six controller numbers are not used for controllers at all but mainly for the Channel Mode Messages discussed previously.
Table 4. Channel Mode Messages.
[All have Status Byte (&Bn) %1011nnnn with two data bytes: %0ccccccc %0vvvvvvv.]
%ccccccc = 122: Local Control
[%vvvvvvv=%0000000: Local Control Off]
[%vvvvvvv=%1111111: Local Control On]
%ccccccc = 123 : All Notes Off
[%vvvvvvv is %0000000 and is ignored]
%ccccccc = 124: OMNI Mode Off/All Notes Off
[%vvvvvvv is %0000000 and is ignored]
%ccccccc = 125: OMNI Mode On/All Notes Off
[%vvvvvvv is %0000000 and is ignored]
%ccccccc = 126: MONO Mode On/POLY Mode Off/All Notes Off
[%vvvvvvv=number of channels for monophonic voice assignments]
%ccccccc = 127: POLY Mode On/MONO Mode Off/All Notes Off
[%vvvvvvv is %0000000 and is ignored]
In Table 4 you will see that controller numbers 124 and 125 turn OMNI Mode off and on respectively. POLY Mode is turned on (and MONO Mode forced off) by 127 and MONO Mode is turned on (and POLY Mode is forced off) by 126. In each of these four messages (except 126) the data byte (%0vvvvvvv) is set to zero and effectively ignored. In 126 the data value is interpreted as having one of the values 0 through 16. If the value is 0 then all the receiving device's voices will be assigned, one per channel, starting with the current channel (%nnnn in the status byte) up to channel 16. If the data value falls in the range 1 to 16 then the number of voices to be assigned is given in the data byte. If you don't know why we should want to do such things, you obviously don't own a Casio synth and should therefore read my previous article!
Controller number 123 instructs the receiving device to turn all notes off (which is also a side-effect of 124 to 127). This is a rather strange message since MIDI is quite happy for everybody to ignore it! At least one synthesizer I know of sends this message whenever all notes being played on its keyboard are released. This is quite a nice idea - it should cut off any 'droning' notes on any synthesizers that are slaved via MIDI to this master synthesizer.
The last controller number to deal with is 122. This is a very important feature of MIDI which some major synthesizer manufacturers have seen fit to ignore - a great pity. This controller acts like one of the switch controllers: if the seven data bits are %0000000 then Local Control is switched off, and if these bits are %1111111 it is switched on. Local Control On connects the receiving synthesizer's keyboard (and controllers in the general sense) to its sound production circuitry giving a direct control link (Figure 3a); this is the default, power-up condition on all (?) MIDI synths. If Local Control is turned off then this direct control path is broken (Figure 3b) ie. the control information flows to MIDI Out (as it did anyway) and the sound production circuits only respond to the MIDI protocol commands coming via MIDI In.
In this state, the keyboard and controllers are able to act effectively as a master keyboard for controlling other synthesizers independently of the local sound production circuitry. The ability to perform keyboard splits, transpositions etc, which the synthesizer perhaps cannot handle on its own, then becomes possible when a computer is used to link the MIDI Out and MIDI In ports of the synthesizer in the Local Control Off state. This sort of set-up will be discussed further in a later article.
Okay folks, that's where I'll switch off the word processor for this month. Have a rest until next time when we'll look at the last three Channel Voice Messages before moving on to the MIDI system messages.
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!