The USENET MIDI Primer Bob McQueer PURPOSE It seems as though many people in the USENET community 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 in about half a dozen newsgroups. This article is an attempt to provide the basic data to the readers of the net. 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. 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. 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 opto-isolated, 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. 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. 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. 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. Most sequencers and keyboards use only this feature instead of 'note off'. The pitch bytes of notes are simply number of half-steps, with middle C = 60 (0x3C) 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 (16383). The 1.0 spec. says that the increment is determined by the receiver. 0x2000 (8192) is to correspond to a centered pitch wheel (unmodified notes) 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. Controller number 1 is standardized to be the modulation wheel. 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. SYSTEM MESSAGES The status bytes 0x80 - 0x8f do not have channel numbers in the lower nibble. These bytes are used as follows: byte purpose data bytes 0xf0 system exclusive variable length 0xf1 undefined 0xf2 song position 2 - 14 bit value, least significant byte first 0xf3 song select 1 - song number 0xf4 undefined 0xf5 undefined 0xf6 tune request 0 0xf7 EOX (terminator) 0 The status bytes 0xf8 - 0xff are the so-called "real-time" messages. I will discuss these after the accumulated notes concerning the first bunch. Song position / song select are for control of sequencers. The song position is in beats, which are to be interpreted as every 6 MIDI clock pulses. These messages determine what is to be played upon receipt of a "start" real-time message (see below). The "tune request" is a command to analog synthesizers to tune their oscillators. The system exclusive message is intended for manufacturers to use to insert any specific messages they want to which apply to their own product. The following data bytes are all to be "data" bytes, that is they are all to be in the range 0 - 127. The system exclusive is to be terminated by the 0xf7 terminator byte. The first data byte is also supposed to be a "manufacturer's id", assigned by a MIDI standards committee. THE TERMINATOR BYTE IS OPTIONAL - a system exclusive may also be "terminated" by the status byte of the next message. some MIDI ID's: Code Manufacturer 0x01 Sequential Circuits 0x02 Big Briar 0x03 Octave / Plateau 0x04 Moog 0x05 Passport Designs 0x06 Lexicon 0x11 PAIA 0x12 Simmons 0x13 Gentle Electric 0x14 Fairlight 0x20 Bon Tempi 0x21 S.I.E.L. 0x23 SyntheAxe 0x40 Kawai 0x41 Roland 0x42 Korg 0x43 Yamaha REAL TIME MESSAGES. This is the final group of status bytes, 0xf8 - 0xff. These bytes are reserved for messages which are called "real-time" messages because they are allowed to be sent ANYPLACE. This includes in between data bytes of other messages. A receiver is supposed to be able to receive and process (or ignore) these messages and resume collection of the remaining data bytes for the message which was in progress. Realtime messages do not affect the "running status byte" which might be in effect. All of these messages have no data bytes following (or they could get interrupted themselves, obviously). The messages: 0xf8 timing clock 0xf9 undefined 0xfa start 0xfb continue 0xfc stop 0xfd undefined 0xfe active sensing 0xff system reset The timing clock message is to be sent at the rate of 24 clocks per quarter note, and is used to sync. devices, especially drum machines. Start / continue / stop are for control of sequencers and drum machines. The continue message causes a device to pick up at the next clock mark. The active sensing byte is to be sent every 300 ms. or more often, if it is used. Its purpose is to implement a timeout mechanism for a receiver to revert to a default state. A receiver is to operate normally if it never gets one of these, activating the timeout mechanism from the receipt of the first one. The system reset initializes to power up conditions. The spec. says that it should be used "sparingly" and in particular not sent automatically on power up.