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 MESSAGES

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.

CHANNEL VOICE MESSAGES

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
%1011nnnn	2	Control Change
%1100nnnn	1	Program Change
%1101nnnn	1	Channel Pressure
%1110nnnn	2	Pitch Wheel Change

The first item in each row of the table is the status byte which will head the message described in the right-hand column of the table. Since the right-hand nybble of this byte is the channel number it is shown as nnnn (4 bits) to indicate that the channel number has no bearing on the channel voice message type. The left-hand bit of all status bytes is set at 1, of course, so we are only left with three bits to actually represent the message type ie. the status byte looks like: 1mmmnnnn (where mmm are three message type bits).

The three bits mmm allow eight possible message types (%000, %001, %010, ...%111) but one of these (%111) is reserved to indicate that we are dealing with system message types rather than channel message types, leaving us with the seven patterns shown in Table 1. [NB. For clarification purposes only, binary numbers are prefixed by %, and hexadecimal numbers by &.] Reading these left-hand nybble patterns we see that they are &8 through to &E for the channel voice messages, with &F being reserved. If we show the right-hand nybble as having the value n (in the range 0 to 15) for representing MIDI channels 1 to 16, then we have the bytes &8n, &9n, ...&En as our status byte values where the MIDI channel number is actually n+1.

The middle column in Table 1 shows the number of data bytes that must follow each channel voice message status byte. Let's now consider Table 2 which describes what each of the data bytes is used for.

Table 2. Channel Voice Message Data Bytes.

Status	Data 1	Data 2	Description of Data Bytes
(&8n)
%1000nnnn	%0kkkkkkk	%0vvvvvvv	Note Off
			%kkkkkkk = (key) note number
			%vvvvvvv = key velocity
(&9n)
%1001nnnn	%0kkkkkkk	%0vvvvvvv	Note On
			%kkkkkkk = (key) note number
			%vwww = key velocity
(&An)
%1010nnnn	%0kkkkkkk	%0ppppppp	Polyphonic Key Pressure
			%kkkkkkk = (key) note number
			%ppppppp = key pressure
(&Bn)
%1011nnnn	%0ccccccc	%0vvvvvvv	Control Change
			%ccccccc ^controller number
			%vwww = controller value for values 0 to 121 (for 122 to 127 see Table 4)
(&Cn)
%1100nnnn	%0ppppppp		Program Change
			%ppppppp = program number
(&Dn)
%1101nnnn	%0ppppppp		Channel Pressure
			%ppppppp = keyboard pressure
(&En)
%1110nnnn	%0LLLLLLL	%0hhhhhhh	Pitch Wheel Change
			%LLLLLLL = low order 7 bits
			%hhhhhhh = high order 7 bits

In Table 2 the channel voice messages are shown in terms of their status byte values (in hexadecimal and binary) in the first column. The following data bytes are shown, in order, in column two (in binary) with the meaning of the messages described in the third column. Note that where a data byte is shown as %0iiiiiii this means that the leftmost bit is off, which it must be for a data byte (since it is only on for status bytes), and the other seven bits (%iiiiiii) form the value we are interested in. If a data byte were to be shown as %0iiijjjj, then the byte would be decoded as two values: a three bit value %iii, and a four bit value % jjjj. We shall see this notation in use next month, so let's now discuss each message in turn.

NOTE OFF (&8n) and NOTE ON (&9n)

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
C-2	0
C-1	12
C0	24
C1	36
C2	48
middle C3	60
C#3	61
D3	62
D#3	63
E3	64
F3	65
F#3	66
G3	67
G#3	68
A3	69
A#3	70
B3	71
C4	72
C5	84
C6	96
C7	108
C8	120
C#8	121
D8	122
D#8	123
E8	124
F8	125
F#8	126
G8	127

Whilst most of us will probably view the correspondence of numbers to semitones as quite sensible (if not almost built in to the very fabric of the musical universe), there are some musicians who see this correspondence as a failure of the MIDI specification. Whilst not planning to go microtonal myself this weekend, I can nevertheless see that any form of music based on intervals other than multiples of the semitone must find MIDI rather galling, since it invites computer control and then doesn't deliver in the microtonal arena. However, since most of the paying customers are quite happy with MIDI's side of this argument I'll move on!

The second data byte in the note on/off messages (%'vwvwv) holds a key velocity value which must also be in the range 0 to 127. This value corresponds to how slowly or quickly you 'played' the key for note on or 'released' the key for note off. In other words, the key velocity corresponds to how hard you hit the key, which would give a velocity value near the 127 end, or how soft you hit the key, which would give a velocity near the 0 end. The same idea applies to the release of keys even though the phrase 'how hard you release the key' doesn't quite sound right!

Not many electronic keyboards actually generate or respond to the note off release velocity so you will often find it stuck at 64, the mid-point value of the velocity range ie. neither hard nor soft, in fact medium! This may well also be the case for the note on velocity but quite a few synthesizers will actually respond to velocity sent over MIDI even though their own keyboards will not generate velocity information! This is simply because the more sophisticated 'touch-sensitive' keyboard required would inflate the price of the instrument. The only synthesizer in (my bank manager's definition of) a sensible price range (!) which I am aware of that produces both note on and note off velocity data is the Oberheim Matrix-6. There are quite a few synthesizers (such as the Yamaha DX7 and the Roland JX-8P) which will produce only note on velocity information.

The note on velocity data has an obvious use in implementing the 'touch-sensitive' nature of the keyboard by modulating the amplitude envelope of a piano sound for example. The MIDI specification advises that a logarithmic scale should be used and this is shown in Figure 2.

Figure 2. Logarithmic Scale For Velocity Values.

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).

POLYPHONIC KEY PRESSURE (&An)

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.

CONTROL CHANGE (&Bn)

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.

CONTINUOUS OR SWITCHED?

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.

ANALOGUE-TO-DIGITAL

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.

CHANNEL MODE MESSAGES

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.

LOCAL CONTROL

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.

HAVE A REST

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.