                                 PURPOSE

It seems as though many people have an interest in the Musical Instrument 
Digital Interface (MIDI), but for one reason or another have only obtained 
word of mouth or fragmentary descriptions of the specification.  Basic 
questions such as "what's the baud rate?", "is it EIA?" and the like seem to 
keep surfacing.  This article is an attempt to provide the basic data to 
MICRONEWS readers.

MICRONEWS

                          The MIDI Primer
                            Bob McQueer

REFERENCE

The major written reference for this article is version 1.0 of the MIDI 
specification, published by the International MIDI Association, copyright 
1983.  There exists an expanded document.  This document, which I have not 
seen, is simply an expansion of the 1.0 spec. to contain more explanatory 
material, and fill in some areas of hazy explanation.  There are no radical 
departures from 1.0 in it.  I have also heard of a "2.0" spec., but the IMA 
claims no such animal exists.  In any event, backwards compatibility with the 
information I am presenting here should be maintained.





CONVENTIONS

I will give constants in C syntax, ie. 0x for hexadecimal.  If I refer to 
bits by number, I number them starting with 0 for the low order (1's place) 
bit.  The following notation:

>>

text

<<

will be used to delimit commentary which is not part of the "bare-bones" 
specification.  A sentence or paragraph marked with a question mark in column 
1 is a point I would kind of like to hear something about myself.

                          OK, let's give it a shot.



PHYSICAL CONNECTOR SPECIFICATION

The standard connectors used for MIDI are 5 pin DIN.  Separate sockets are 
used for input and output, clearly marked on a given device.  The spec. gives 
50 feet as the maximum cable length.  Cables are to be shielded twisted pair, 
with the shield connecting pin 2 at both ends. The pair is pins 4 and 5, pins 
1 and 3 being unconnected:

                              2
                          5       4
                        3           1


A device may also be equipped with a "MIDI-THRU" socket which is used to pass 
the input of one device directly to output.

>>
I think this arrangement shows some of the original conception of MIDI more 
as a way of allowing keyboardists to control multiple boxes than an 
instrument to computer interface.  The "daisy-chain" arrangement probably has 
advantages for a performing musician who wants to play "stacked" synthesizers 
for a desired sound, and has to be able to set things up on the road. <<






ELECTRICAL SPECIFICATION

Asynchronous serial interface.  The baud rate is 31.25 Kbaud (+/- 1%). There 
are 8 data bits, with 1 start bit and 1 stop bit, for 320 microseconds per 
serial byte.

MIDI is current loop, 5 mA.  Logic 0 is current ON.  The specification states 
that input is to be optoisolated, and points out that Sharp PC-900 and HP 
6N138 optoisolators are satisfactory devices.  Rise and fall time for the 
optoisolator should be less than 2 microseconds.

The specification shows a little circuit diagram for the connections to a 
UART.  I am not going to reproduce it here.  There's not much to it - I think 
the important thing it shows is +5 volt connection to pi 4 of the MIDI out 
with pin 5 going to the UART, through 220 ohm load resisors. It also shows 
that you're supposed to connect to the "in" side of the UART through an 
optoisolator, and to the MIDI-THRU on the UART side of the isolator.

        






>>


I'm not much of a hardware person, and don't really know what I'm talking 
about in paragraphs like the three above.  I DO recognize that this is a 
"non-standard" specification, which won't work over serial ports intended for 
anything else.  People who do know about such things seem to either have 
giggling or gagging fits when they see it, depending on their dispositions, 
saying things like "I haven't seen current loop since the days of the old 
teletypes".  I also know the fast 31.25 Kbaud pushes the edge for clocking 
commonly available UART's. 

<<











DATA FORMAT

For standard MIDI messages, there is a clear concept that one device is a 
"transmitter" or "master", and the other a "receiver" or "slave". Messages 
take the form of opcode bytes, followed by data bytes. Opcode bytes are 
commonly called "status" bytes, so we shall use this term.

>>

Very similar to handling a terminal via escape sequences.  There aren't ACK's 
or other handshaking mechanisms in the protocol.

<<

Status bytes are marked by bit 7 being 1.  All data bytes must contain a 0 in 
bit 7, and thus lie in the range 0 - 127.







MIDI has a logical channel concept.  There are 16 logical channels, encoded 
into bits 0 - 3 of the status bytes of messages for which a channel number is 
significant.  Since bit 7 is taken over for marking the status byte, this 
leaves 3 opcode bits for message types with a logical channel.  7 of the 
possible 8 opcodes are used in this fashion,  reserving the status bytes 
containing all 1's in the high nibble for "system" messages which don't have 
a channel number.  The low order nibble in these remaining messages is really 
further opcode.

>>

If you are interested in receiving MIDI input, look over the SYSTEM messages 
even if you wish to ignore them.  Especially the "system exclusive" and "real 
time" messages.  The real time messages may be legally inserted in the middle 
of other data, and you should be aware of them, even though many devices 
won't use them. 

<<





VOICE MESSAGES

I will cover the message with channel numbers first.  The opcode determines 
the number of data bytes for a single message (see "running status byte", 
below).  The specification divides these into "voice" and "mode" messages. 
The "mode" messages are for control of the logical channels, and the control 
opcodes are piggybacked onto the data bytes for the "parameter" message.  I 
will go into this after describing the "voice messages".  These messages are:

status byte   meaning        data bytes

0x80-0x8f     note off       2 - 1 byte pitch, followed by 1 byte velocity
0x90-0x9f     note on        2 - 1 byte pitch, followed by 1 byte velocity
0xa0-0xaf     key pressure   2 - 1 byte pitch, 1 byte pressure (after-touch)
0xb0-0xbf     parameter      2 - 1 byte parameter number, 1 byte setting
0xc0-0xcf     program        1 byte program selected
0xd0-0xdf     chan. pressure 1 byte channel pressure (after-touch)
0xe0-0xef     pitch wheel    2 bytes giving a 14 bit value, least
                                   significant 7 bits first

Many explanations are necessary here:

For all of these messages, a convention called the "running status byte" may 
be used.  If the transmitter wishes to send another message of the same type 
on the same channel, thus the same status byte, the status byte need not be 
resent.

Also, a "note on" message with a velocity of zero is to be synonymous with a 
"note off".  Combined with the previous feature, this is intended to allow 
long strings of notes to be sent without repeating status bytes.


>>

From what I've seen, the "zero velocity note on" feature is very heavily 
used.  My six-trak sends these, even though it sends status bytes on every 
note anyway.  Roland stuff uses it.

<<

The pitch bytes of notes are simply number of half-steps, with middle C = 60.

>>      

On keyboard synthesizers, this usually simply means which physical key 
corresponds, since the patch selection will change the actual pitch range of 
the keyboard.  Most keyboards have one C key which is unmistakably in the 
middle of the keyboard.  This is probably note 60.

<<

The velocity bytes for velocity sensing keyboards are supposed to represent a 
logarithmic scale.  "advisable" in the words of the spec.  Non-velocity 
sensing devices are supposed to send velocity 64.

The pitch wheel value is an absolute setting, 0 - 0x3FFF.  The 1.0 spec. says 
that the increment is determined by the receiver. 0x2000 is to correspond to 
a centered pitch wheel (unmodified notes)

>>

I believe standard scale steps are one of the things discussed in expansions.  
The six-trak pitch wheel is up/down about a third. I believe several makers 
have used this value, but I may be wrong.

The "pressure" messages are for keyboards which sense the amount of pressure 
placed on an already depressed key, as opposed to velocity, which is how fast 
it is depressed or released.

I'm not really certain of how "channel" pressure works.  Yamaha is one maker 
that uses these messages, I know.

<<

Now, about those parameter messages.

Instruments are so fundamentally different in the various controls they have 
that no attempt was made to define a standard set, like say 9 for "Filter 
Resonance".  Instead, it was simply assumed that these messages allow you to 
set "controller" dials, whose purposes are left to the given device, except 
as noted below.  The first data bytes correspond to these "controllers" as 
follows:

data byte

0 - 31       continuous controllers 0 - 31, most significant byte
32 - 63      continuous controllers 0 - 31, least significant byte
64 - 95      on / off switches

96 - 121     unspecified, reserved for future.
122 - 127    the "channel mode" messages I alluded to above.  See
             below.





The second data byte contains the seven bit setting for the controller. The 
switches have data byte 0 = OFF, 127 = ON with 1 - 126 undefined. If a 
controller only needs seven bits of resolution, it is supposed to use the 
most significant byte.  If both are needed, the order is specified as most 
significant followed by least significant.  With a 14 bit controller, it is 
to be legal to send only the least significant byte if the most significant 
doesn't need to be changed.

>>

This may of, course, wind up stretched a bit by a given manufacturer. The 
Six-Trak, for instance, uses only single byte values (LEFT justified within 
the 7 bits at that), and recognizes >32 parameters

<<

Controller number 1 IS standardized to be the modulation wheel.  Are there 
any other standardizations which are being followed by most manufacturers?







MODE MESSAGES

These are messages with status bytes 0xb0 through 0xbf, and leading data 
bytes 122 - 127.  In reality, these data bytes function as further opcode 
data for a group of messages which control the combination of voices and 
channels to be accepted by a receiver.

An important point is that there is an implicit "basic" channel over which a 
given device is to receive these messages.  The receiver is to ignore mode 
messages over any other channels, no matter what mode it might be in. The 
basic channel for a given device may be fixed or set in some manner outside 
the scope of the MIDI standard.











The meaning of the values 122 through 127 is as follows:

data byte                   second data byte
122       local control     0 = local control off, 127 = on
123       all notes off     0
124       omni mode off     0
125       omni mode on      0
126       monophonic mode   number of monophonic channels, or 0
                            for a number equal to receivers voices
127       polyphonic mode   0

124 - 127 also turn all notes off.

Local control refers to whether or not notes played on an instruments 
keyboard play on the instrument or not.  With local control off, the host is 
still supposed to be able to read input data if desired, as well as sending 
notes to the instrument.  Very much like "local echo" on a terminal, or "half 
duplex" vs. "full duplex".

The mode setting messages control what channels / how many voices the 
receiver recognizes.  The "basic channel" must be kept in mind. "Omni" refers 
to the ability to receive voice messages on all channels.  "Mono" and "Poly" 
refer to whether multiple voices are allowed.  The rub is that the omni 
on/off state and the mono/poly state interact with each other.  We will go 
over each of the four possible settings, called "modes" and given numbers in 
the specification:

mode 1 - Omni on / Poly - voice messages received on all channels and
         assigned polyphonically.  Basically, any notes it gets, it
         plays, up to the number of voices it's capable of.

mode 2 - Omni on / Mono - monophonic instrument which will receive
         notes to play in one voice on all channels.

mode 3 - Omni off / Poly - polyphonic instrument which will receive
         voice messages on only the basic channel.

mode 4 - Omni off / Mono - A useful mode, but "mono" is a misnomer.
         To operate in this mode a receiver is supposed to receive
         one voice per channel.  The number channels recognized will be
         given by the second data byte, or the maximum number of possible
         voices if this byte is zero.  The set of channels thus defined
         is a sequential set, starting with the basic channel.
The spec. states that a receiver may ignore any mode that it cannot honor, or 
switch to an alternate - "usually" mode 1.  Receivers are supposed to default 
to mode 1 on power up.  It is also stated that power up conditions are 
supposed to place a receiver in a state where it will only respond to note on 
/ note off messages, requiring a setting of some sort to enable the other 
message types.

>>

I think this shows the desire to "daisy-chain" devices for performance from a 
single master again.  We can set a series of instruments to different basic 
channels, tie 'em together, and let them pass through the stuff they're not 
supposed to play to someone down the line.

This suffers greatly from lack of acknowledgement concerning modes and usable 
channels by a receiver.  You basically have to know your device, what it can 
do, and what channels it can do it on.

I think most makers have used the "system exclusive" message (see below) to 
handle channels in a more sophisticated manner, as well as changing "basic 
channel" and enabling receipt of different message types under host control 
rather than by adjustment on the device alone.

To continue, press ENTER                                    <MIDIEX2>
