CHAPTER 9 MIDI
The most commonly used MIDI message types are listed in the text, and these are applicable to the majority of uses readers are likely to need. There are times, however, when “legacy” or less common messages may present themselves, such as when using a vintage piece of hardware, or in some programming contexts. These “road less travelled” messages are listed here for reference.
Many of these messages are special uses of the Control Change message. At a software level there is no distinction between one Control Change type or another – they are simply numbers identifying streams of information that can be used in any manner desired. There are, however, certain standardized uses of controllers. Some of these are listed in the text, and many were adopted with the introduction of General MIDI.
Another special use of Control Change messages were MIDI Mode messages, which were used to change the operating modes of early synthesizers, defining how they responded to MIDI messages.
In 1983, the specification’s allowance of 128 controller types was well beyond the number of types of controller hardware. MIDI Mode Change messages became the first example of the control change message category being used as a miscellaneous repository for other message types, utilizing controller numbers 120-127.
MIDI Mode Message Types
Channel Mode Messages
There were two types of MIDI Mode Messages. The first type wereChannel Mode Messages, which defined two possible states of two parameters: Omni On/Off and Poly/Mono. Four controller numbers determined the four combinations possible with these two parameters:
Omni
1. Off: The device responded to messages on one channel only (controller 124).
2. On: The device responded to messages on any channel (controller 125).
Mono
3. The device could only play one note at a time (controller 126).
Poly
4. The device could play polyphonically (multiple notes simultaneously) (controller 127).
Because each parameter was addressed by a Control Change message, two Control Change messages were required to define a complete change of mode. The four modes are listed below.
Mode 1: Omni On/Poly
Hex Binary
Bn1011nnnnStatus: Control Change/channel number
7D01111101Controller 125: Omni On
0000000000Value: the device does not respond to the value byte from controllers 124 and 125>
Bn1011nnnnStatus: Control Change/channel number
7F01111111Controller 127: Poly On
0000000000Value: the device does not respond to the value byte from controller 127 when it follows controller 125>
In Mode 1, an instrument would respond polyphonically to MIDI messages on any channel. This mode was meant for troubleshooting to make sure a device was responding to MIDI messages. It had little use in musical applications.
Mode 2: Omni On/Mono
Hex Binary
Bn1011nnnnStatus: Control Change/channel number
7D01111101Controller 125: Omni On
0000000000Value: the device does not respond to the value byte from controllers 124 and 125>
Bn1011nnnnStatus: Control Change/channel number
7E01111110Controller 126: Mono On
0000000000Value: the device does not respond to the value byte from controller 126 when it follows controller 125>
In Mode 2, an instrument would respond monophonically to messages on any channel. This mode had limited usefulness and was rarely used. (On many instruments, it was not even implemented.) This combination of mode parameters came about more by the mode definition structure than out of any practicality.
Mode 3: Omni Off/Poly
Hex Binary
Bn1011nnnnStatus: Control Change/channel number
7C01111100Controller 124: Omni Off
0000000000Value: the device does not respond to the value byte from controllers 124 and 125>
Bn1011nnnnStatus: Control Change/channel number
7F01111111Controller 127: Poly On
0000000000Value: the device does not respond to the value byte from controller 127 when it follows controller 124
In Mode 3, an instrument would respond polyphonically to messages on one channel only. In the 1980s, this was the standard mode for studio configurations in which each instrument was set to respond to messages on one base channel.
Mode 4: Omni Off/Mono
Hex Binary
Bn1011nnnnStatus: Control Change/channel number
7C01111100Controller 124: Omni Off
0000000000Value: the device does not respond to the value byte from controllers 124 and 125>
Bn1011nnnnStatus: Control Change/channel number
7E01111110Controller 126: Mono On
0000000000Number of channels to receive; SEE EXPLANATION BELOW
In Mode 4, an instrument would respond monophonically to messages on one channel only. In the 1980s, many instruments featured a portamento effect, in which one pitch would slide to the next during legato playing when Mode 4 was activated. As MIDI instruments expanded beyond keyboard types, Mode 4 became the standard mode for wind or string controller instruments.
In the early 1990s, this mode took on a special implementation in many polyphonic devices. As MIDI instrument design developed, manufacturers began to create instruments that could respond to messages on more than one channel.This was different from Omni On, which implied that an instrument was insensitive to the channel portion of a MIDI message. This new feature signified, rather, a new type of mode in which an instrument had a number of “subinstruments,” or parts, each of which was set to play messages on one particular channel polyphonically. These multitimbral devices responded differently to Mode 4: when Mode 4 was activated, they operated in Multi Mode, which was not monophonic.
For Multi Mode instruments, the last byte of the Mono On message determined how many channels the instrument would respond to. If the third byte had a value of 0, then the instrument responded to as many channels as it had parts (typically 16). However, it was sometimesbe desirable for a Multi Mode instrument to respond to fewer than 16 channels. If the second nibble of the value byte had a value within the range of 1 to 15, the instrument would respond to the number of channels corresponding to the value of this nibble, starting with channel 1. For example, if the nibble had a value of 5, the instrument would respond to messages on channels 1 through 5.
Other Types of Mode Messages
In addition to the four channel modes, there were four other types of mode messages that controlled how a device responded to MIDI messages.
All Notes Off (controller 123)
Hex Binary
Bn1011nnnnStatus: Control Change/channel number
7B01111011Controller 123:All Notes Off
0000000000Value: the device did not respond to the value byte from controller 123
This message would send a Note Off to all notes on the specified channel (except those notes currently being played). This would eliminate “stuck notes” on an instrument, a condition that sometimes occurred following a large amount of MIDI activity: sometimes a Note Off would get lost, resulting in a note continuing to sound.
All Sound Off (controller 120)
Hex Binary
Bn1011nnnnStatus: Control Change/channel number
7801111000Controller 120:All Sound Off
0000000000Value: the device did not respond to the value byte from controller 120
On receiving this message, an instrument would immediately mute all notes, regardless of any envelope release times that would normally follow a Note Off message. This was more immediate and global than an All Notes Off message. It was a useful command to send when the “Stop” button was hit in a sequencer program.
Reset All Controllers (controller 121)
Hex Binary
Bn1011nnnnStatus: Control Change/channel number
7901111001Controller 121: Reset All Controllers
0000000000Value: the device did not respond to the value byte from controller 121
On receiving this message, an instrument would return all controllers to their default state (Mod Wheel to 0, Pan to 64, and so on).
Local Control (controller 122)
Hex Binary
Bn1011nnnnStatus: Control Change/channel number
7A01111010Controller 122:Local Control
00-7F0nnnnnnn Value byte: 0–63 = Off; 64–127 = On
This message would disable the sound-generating circuitry of a device, so that it only functioned to send MIDI information to other devices. In many cases, a Volume setting of zero would have the same auditory effect. Turning Local Control off, however, was more efficient computationally. Even when a device has its volume lowered, it still constantly scans its status for held notes, Aftertouch, wheel settings,etc.This command stopped it from doing this extra work. Also, there could be multi-instrument performance configurations in which a device might be able to receive information that it was also sending. Turning Local Control to Off alleviated any MIDI feedback problems from such a configuration.
System-Level Messages
System messages 2343 meant to address not just one device, but all devices on a MIDI network. System messages are in the form:
Hex Binary
Fn1111nnnn
The first nibble identifies it as a System message, with the second nibble defining message type. (Note: this explains why there are only seven out of a possible eight Channel Voice messages. The most significant nibble, 1111, is reserved for System Level messages.) Some System messages required more bytes, others were a single byte in length.
System Common Messages
System Common messages addressed certain housekeeping issues in preparing instruments for an appropriate playing state. These messages fell within the range
Hex Binary
F1-F711110001-11110111
MIDI Time Code Quarter Frame
Hex Binary
F111110001MTC Quarter Frame
0nnnnnnntimestamp
This message type was used for synchronizing MIDI with SMPTE timecode used in video. (SMPTE synchronization is discussed in Chapter 11 of the textbook.) The first byte is a MTC Quarter Frame identifier, signifying that the next byte will be a component of the SMPTE hour:minute:second:frametimecode specification. Two MTC byte pairs are required to specify a value for each of the four time fields (hence the name, as each set of pairs specifies one quarter of the total specification).Thus, 16 bytes are needed to transmit the time coordinates of a given frame. This and the next message type will be covered in more detail below, in the section “MIDI and Time.”
Song Position Pointer
Hex Binary
F211110010Song Position Pointer
0nnnnnnn beat position, least significant byte
0nnnnnnn beat position, most significant byte
This message type was used to set a sequencer or drum machine to start at a point other than the beginning of a sequence, some specified number of MIDI beats from the sequence’s first beat. MIDI beats will be covered in more detail below, in the section “MIDI and Time.”
Song Select
Hex Binary
F311110011Song Select
0nnnnnnnsong number
This message type was used to choose a particular sequence number from memory; it was the equivalent of a Program Change message, directed to a sequencer or drum machine file.
Tune Request
Hex Binary
F611110110
This message sent a command for analog synthesizers to tune themselves.
End System Exclusive
Hex Binary
F711110111
System Exclusive is another message class, which is covered in the textbook. Because of extra available bits in the System Common range, this command was defined with a System Common message number.
System Real-Time Messages
This message class was for controlling clock-based operations during playback. They are all 1 byte, and their range is 11111nnn.
Timing Clock
Hex Binary
F811111000
When active, a Timing Clock byte was transmitted 24 times per quarter note as a metronome pulse to keep slaved instruments in synchronization with the timing master. In the 1980s, a complex performance setup might have involved a number of dedicated sequencers and drum machines, all running in tandem. Timing Clock messages could also be used in conjunction with instruments that had on-board sequencers. A series of these could act as slave sequencers under the control of a master sequencer. With all slave instruments configured to receive time information from Timing Clock messages, the master clock device could keep them all in tempo by means of Timing Clock synchronizing pulses.
Sequence Start
Hex Binary
FA11111010
Begin playback of a sequence from its beginning.
Sequence Continue
Hex Binary
FB11111011
Resume playback of a paused sequence from the current position.
Stop
Hex Binary
FC11111100
Halt playing a sequence immediately.
Active Sensing
Hex Binary
FE11111100
This byte announced “I am still here,” and was sent at least every 300 msec when a device was sending no other information. Its purpose was to allow a sequencer to verify that all devices remained connected, and that no MICI cables had become disconnected.
System Reset
Hex Binary
FF11111111
This byte returned all of an instrument’s values to factory presets, meant for use extreme emergency situations.
System Exclusive Messages (Sysex)
This message class allowed devices to be addressed in ways not covered by the MIDI standard. Sysex messages are covered in the textbook in Chapter 9.
MIDI and Time
The MIDI specification provided for a variety of event types, but it contained no information about time or duration. A sequencer allowed a certain degree of time control by adding timestamps to MIDI events. But an added level of time control was necessary for multiple time-based devices to work together. To address this need, MIDI did have specifications by which multiple clock-based devices could operate in synchronization.
MIDI Synchronization
Two types of MIDI synchronization were created, designed to address situations such as the following:
Example 1: A live performance might involve multiple sequencers and drum machines. All devices needed a common clock source if they were to play together.
Example 2: A studio project might involve work with a multitrack tape deck and a sequencer. Each tape track might record a multitrack (MIDI) sequence. The tape deck and the sequencer needed a common clock source so that successive recordings on separate tape tracks were in synchronization.
Relative synchronization used clicks—in the form of voltage changes—to act as a common metronome pulse among devices. Relative synchronization was simple and economical to implement, but lacked flexibility. All pulses were the same, based on the piece’s tempo. Therefore, the piece always had to be run from the beginning to ensure that all devices were playing at the same place in the piece.
Absolute synchronization involved the use of distinct pulses, each containing a time address. A common form of synchronization was SMPTE, which is discussed in the textbook in Chapter11. Although this was a more complicated method of transmission, it was much more flexible than relative synchronization. Playback or recording could begin from any point in a piece. This was much more convenient when creating material that was to be placed several minutes into the piece.
MIDI Clock
MIDI Clock was a MIDI form of relative synchronization. A Timing Clock message, described earlier, was used as a “conductor track,” a common pulse that governed all devices. It was based on a resolution of 24 pulses per quarter note (ppqn). This was a useful subdivision since 24 can be divided by 2 or 3, allowing resolution to 64th-note triplets.
Song Position Pointer
Synchronization of devices by pulses existed prior to the creation of MIDI. But one of MIDI’s innovations was to allow sequences to play from a point other than the beginning of a piece. Song Position Pointer messages allowed an offset of a specified number of MIDI Clock pulses as a playback starting point.
Frequency Shift Keying (FSK)
MIDI Clock messages allowed devices to be synchronized via MIDI, as in the first synchronization example. For MIDI devices to be synchronized with tape decks, as in the second synchronization example, MIDI Clock pulses had to be converted to an audio signal that could be recorded to tape. Pulses were converted to a tone that alternated regularly in frequency, an FSK signal. This audio signal could then act as the pulse source to drive other devices.
FSK allowed MIDI to be recorded on multiple tape tracks by the following steps:
- The sequencer was set to run from its internal clock.
- The FSK pulse was sent to an input of the tape deck to be recorded on one track of the tape.
- The sequence was run, but no instruments were recorded. Only the FSK signal was recorded to tape. Recording the synchronization signal on one track was termed “striping” the tape.
- The tape was rewound.
- The sequencer was set to run by external clock.
- Audiooutwasconnectedfromthestripedtapetracktothesequencer’s clock source.
- Theinstrument’saudiooutwasdirectedtoanothertapetrack.
- PLAYwasactivatedonthesequencer.Withthesequencersettoexternal clock mode, playback would not start until OVERDUB/RECORD was activated on the tape deck. At that point the master clock signal was sent to the sequencer and playback would commence.
- Attheendofthepiece,thetapewasrewound.
- Appropriate adjustments were made to the MIDI instrument (such as patch changes). Its audio output was sent to another tape track. The sequence was run again, OVERDUB/RECORD was activated on the tape deck, and the next track was recorded.
This process would be repeated until all MIDI tracks were recorded onto all necessary tape tracks.
MIDI Time Code (MTC)
MTC represented absolute time synchronization, in which pulses were not generic, but rather were associated with a timestamp. Thus, each pulse contained information about where in the piece it occured. MTC was a MIDI translation of SMPTE timecode, the standard used for synchronizing video in the film and television industry
In SMPTE timecode, timestamps are defined by four fields: hour:minute:second:frame. Thus, a MIDI sequencer, set to run by an external SMPTE signal, could be used to score a video meant for film or TV. A sequencer slaved to a SMPTE synchronization signal allowed music or sound effects to be placed at the correct frame to match visual cues. The steps for using a sequencer and a tape deck striped with SMPTE code were the same as those in FSK synching, with the added element of a VCR. A VCR with a SMPTE-striped video acted as the master for both a tape deck and a sequencer.
The function of MIDI Time Code Quarter Frame messages was to translate between SMPTE and MIDI. hour:minute:second:frame are each defined by 4 bytes, two pairs of 2 bytes. The first byte of a pair was an MTC identifier, and the second gave information about one of the four time coordinate fields. Each SMPTE field was defined by an 8-bit byte. The second byte of each pair contributed one nibble to this 8-bit byte. The three Figures below illustrate how 16 bytes are used to define the four fields that define a given video frame.