Guide to the MIDI Software Specification

Running Status

Running Status is a data-thinning technique. It allows for the omission of status bytes if the current message to be transmitted has the same status byte (i.e. the same command and MIDI channel) as the previous message. It thus only applies to Channel (Voice and Mode) messages (0x8n - 0xEn).

System Real Time messages (0xF8 - 0xFF) are all single byte messages, and so running status is not applicable. Also, they can be interleaved within other messages without affecting running status in any way.

System Common and System Exclusive messages (0xF0 - 0xF7), on the other hand, cancel any running status, so any message following one of these messages must contain a status byte. As with System Real Time messages, running status is not applicable to System Common and System Exclusive messages, so these messages must always contain a status byte.

E.g. to play the C Major chord based on middle C :

Without running status :

With running status, the second and third status bytes are omitted :

Both approaches are valid, and so either may be used.

Coding issues

To be able to cope with running status, a receiving device should always remember the last status byte that it received (except for System messages), and if it doesn't receive a status byte when expected (on subsequent messages), it should assume that it's dealing with a running status situation. Apart from System Real Time messages, new status bytes will always force a receiver to adopt that new status, even if the previous message was incomplete.

A device that generates MIDI messages should always remember the last status byte that it sent (except for System Real Time messages), and if it needs to send another message with the same status (Channel messages only, not System messages), the status byte may be omitted.

Note messages

Running status is the reasoning behind the velocity = 0 variant of the Note On message (which acts as a Note Off).

E.g. to play the same C Major chord as above (though also turning it off this time) :

Without running status :

With running status, and using Note On with velocity = 0, to act as Note Offs :

Bank Select

Controller numbers 0 (MSB) and 32 (LSB) are used for Bank selection.

The concept of instrument banks was introduced to get around the 128 voice limit of the Program Change message. The bank number is a 14-bit value, hence 16384 different banks are theoretically possible. The Program Change message gives access to up to 128 voices, from within the currently selected bank. There is, however, no requirement for a bank to contain the full set of 128 voices.

The Bank Select message should be transmitted as a pair, and then followed by a Program Change message :

The 14-bit Bank Select value gives access to 16,384 banks using the formula :

E.g. :

Portamento Control (PTC)

Controller number 84 is used for Portamento Control.

When a Note On message is received after a PTC message, the voice's pitch glides from the key number specified in the PTC message to the new Note On's pitch at the rate set by Controller 5 (Portamento Time), ignoring the current status of Controller 65 (Portamento On/Off).

A PTC message only affects the next Note On received on the relevant MIDI channel.

When in Poly mode, receiving a PTC message does not affect the pitch of any currently playing notes (whether in their sustain or release phase).

When in Mono mode, or if Controller 68 (Legato footswitch) is On, a new overlapping note event results in an immediate pitch jump to the note number specified in the PTC message, and then a glide at the current portamento rate to the note number specified in the new Note On.

For an explanation of Mono and Poly modes see the MIDI Modes sub-section under Channel Mode Messages.

The note is turned off by a Note Off which matches the Note On key number, not the key number specified in the PTC message, irrespective of mode.

Example usage :

To perform a glide from C4 to E4 :

RPNs and NRPNs

Controller numbers 98 & 99 (Non-Registered Parameter Number, LSB & MSB), and 100 & 101 (Registered Parameter Number, LSB & MSB), in conjunction with Controller numbers 6 & 38 (Data Entry, MSB & LSB), 96 (Data Increment), and 97 (Data Decrement) extend the number of controllers available via MIDI.

Their use involves selecting the parameter number to be edited using Controllers 98 & 99 or 100 & 101, and then adjusting the value for that parameter using Controller number 6/38, 96, or 97. Controllers 6/38 would be used to set a specific value, whereas Controllers 96 and 97 would be used to nudge the current value up or down, respectively (with the Data2 byte specifying the step size, 1-127).

Note that two 7-bit values are used both to specify the RPN/NRPN itself, and its value. I.e. there are 16,384 possible RPNs (and 16,384 NRPNs) each of which can be set with 14-bit precision. The MSB and LSB data values need not represent a single 0-16,383 range, and can be used to represent different quantities, as in the case of RPN 00,00 (Pitch Bend Sensitivity) where the MSB represents 'semitones' and the LSB represents 'cents'.

To calculate the full number from its LSB and MSB : N = MSB * 128 + LSB

Once the required RPN/NRPN has been specified (using CC98 & CC99, or CC100 & CC101) the value needs to be specified. There are several options :

• High resolution values (i.e. ranging 0-16,383) require two messages :
  • A CC6 Data Entry message, where the Data2 byte contains the MSB of the value.
  • A CC38 Data Entry message, where the Data2 byte contains the LSB of the value.
• Low resolution values (i.e. 0-127) can be sent in one message. It could be either a CC6 or a CC38 Data Entry message.
• A CC96 Data Increment message can be sent. Its Data2 byte holds a value (0-127) to be added to the current parameter value.
• A CC97 Data Decrement message can be sent. Its Data2 byte holds a value (0-127) to be subtracted from the current parameter value.

None of the Non-Registered Parameter Numbers have been assigned specific functions. They may be used for different functions by different manufacturers, and are thus manufacturer-specific.

Registered Parameter Numbers are those which have been assigned some particular function by the MIDI Manufacturers Association (MMA) and the Japan MIDI Standards Committee (JMSC). The following RPNs are currently defined :

It is recommended that the Null Function (RPN 7F,7F) should be sent immediately after a RPN or NRPN and its value are sent.

Example usage :

To set the Pitch Bend Sensitivity on channel 'n' to +/- 7 semitones (ie +/- a fifth) :

Or, to set Tuning Program 'tt' on channel 'n' :

Or, to increment (by 1) the current Tuning Bank on channel 'n' :

When sending successive RPN (or NRPN) messages, the standard allows the ommision of CC100 & CC101 (or CC98 & CC99) if their value is unchanged.

For example, to send a pair of Channel Coarse Tuning and Channel Fine Tuning RPN messages (with a low-res and high-res data value, respectively) :

MIDI Modes

The MIDI specification allows for four basic modes of operation, selected using any two from the last four Channel Mode messages from the above list.

When Omni Mode is on, a device will respond to Channel messages on any MIDI channel, whereas when Omni Mode is off, a device will only respond to Channel messages which are on that device's base channel.

When Mono Mode is on, a device will only be able to play a single note at any time on a given MIDI channel, whereas when Poly Mode is on, a device will be able to play chords on a given channel (within that device's polyphony capability).

Note that any of these Channel Mode messages will only be responded to if they are on the receiving device's base channel. So, even when in Omni mode, a device still has a base channel as such (for the purposes of these Channel Mode messages).

Omni Mode On is a failsafe approach when connecting two devices together, as it ensures that the receiving device will respond to messages sent by the transmitting device. It is, however, totally useless in a sequencer based setup.

Multitimbral devices operate in a slightly special way. Basically each part (which has its own MIDI channel) is considered as a separate device, with each part being set to Omni Mode Off and Poly Mode On (i.e. independent polyphonic channels), which is ideal for use in a sequencer setup.

1 : Omni On, Poly On

Voice messages are received from all voice channels and assigned to voices polyphonically.

All voices are transmitted on the base channel.

2 : Omni On, Mono On

Voice messages are received from all voice channels, and control only one voice, monophonically.

Voice messages for one voice are transmitted on the base channel.

3 : Omni Off, Poly On

Voice messages are received on the base channel only, and assigned to voices polyphonically.

Voice messages for all voices are transmitted on the base channel.

4 : Omni Off, Mono On

Voice messages are received on voice channels <base channel> to <base channel> + nn - 1, and assigned monophonically to voices 1 to nn, respectively. The number of voices 'nn' is specified by the third byte of the Mono Mode message.

Voice messages for voices 1 to nn are transmitted on voice channels <base channel> to <base channel> + nn - 1, respectively (a single voice per channel).

Handshaking

There are five handshaking messages (EOF, ACK, NAK, Wait and Cancel), used in association with the Sample Dump Standard or File Dump messages. Their use is described in the Dump Procedure.

End of File (EOF)

This message signifies that the end of the file has been reached and that the data transfer has been completed successfully.

Wait

The use of this message implies 'Do not send any more packets until told to do so'. This is important for systems where the receiver needs time to perform other processing before receiving the remainder of the sample dump. An ACK will resume the dump, whereas a Cancel will abort it.

Cancel

The use of this message implies 'Abort dump'. The packet number refers to the packet on which the abort takes place.

NAK

The use of this message implies 'The last data packet was received incorrectly - Please re-send'. The packet number refers to the packet being rejected.

ACK

The use of this message implies 'The last data packet was received correctly - Start sending the next one'. The packet number refers to the packet being acknowledged as correct.

Dump Procedure

This applies to the Sample Dump and File Dump standards and involves the transfer of data from sender to receiver. The transfer process can be initiated by either device.

The receiver can initiate the process by sending the appropriate (Sample or File) Dump Request message to the sender, whereas the sender can initiate the process by sending the appropriate (Sample or File) Dump Header message.

Sender

Either upon reception of a Dump Request, or in response to user input on the device's front panel, a Dump Header message is sent.

A timeout scheme is used to determine whether the open loop (no handshaking) or closed loop (with handshaking) protocol is to be used. The sender will wait for up to 2 seconds for a response, after which it will time out. Within this timeout period :

• If it receives a Cancel, it will immediately abort the dump process.
• If it receives an ACK, it will begin transfer by sending the first Data Packet.
• If it receives a Wait, it will suspend transfer indefinitely until another message (ACK or Cancel) is received, which will then be processed as above.
• If nothing is received within the timeout period (2s), the open loop protocol is assumed, and the dump starts with the first packet.

After sending each packet, the sender will wait at least 20ms for a response, after which it will time out. Within this timeout period :

• If it receives an ACK, it will send the next Data Packet.
• If it receives an NAK, and the packet number matches the number of the last packet sent, it will re-send that packet. If the packet numbers do not match, and the device is incapable of sending packets out of sequence, the NAK will be ignored, and the transfer process will continue.
• If it receives a Wait, it will suspend transfer indefinitely until one of ACK, NAK, or Cancel is received, whereupon it will continue.
• If no messages are received within the timeout period (20ms), the sender will assume that the open loop protocol is in effect, and the next packet will be sent.

This process continues until there are less than 121 data bytes remaining to be sent. The final packet will still consist of 120 bytes, regardless, with the excess bytes all being 0.

Receiver

Whilst receiving a Sample or File Data Packet, a device should keep a running checksum. This calculated checksum can be compared with the checksum within the Data Packet to ascertain whether or not the data was received correctly :

• If the checksums match, the receiver will send an ACK and await the next packet.
• If the checksums do not match, it will send a NAK containing the number of the packet that caused the error, and await the next packet. If, after sending a NAK, the packet number of the next packet doesn't match the previous packet number (the one that was NAK'd), and the unit is not capable of accepting packets out of sequence, the error is ignored and the dump continues as if the checksums had matched.

If a receiver runs out of memory before the dump is completed, it will send a Cancel to stop the dump.

MTC Cueing

These messages allow timecode based event lists to be set up.

There is a corresponding set of Real Time MIDI Cueing messages, which take effect immediately.

Cueing Setup

Sample Dump Extensions

With the passage of time since the original Sample Dump Standard, a number of shortcomings had become apparent :

• Only a single loop could be specified.
• An inability to name samples.
• A 2MB sample limit.
• Limited precision for describing the sample rate.

The following messages were added as an extension to the Sample Dump Standard, to address these limitations.

The first two messages overcome the 'single loop' shortcoming by allowing up to 16,383 pairs of loop points to be defined for each sample. They also allow loop points to be modified without having to re-send the entire sample.

Loop Point Transmission

Loop Point Request

With the exception of the Request all loops and Delete all loops commands (when Loop Number = 7F 7F), the Loop Point Request and Loop Point Transmission messages affect a single loop point (start and end points).

Loop number 00 00 is the same as the sustain loop as defined in the SDS.

The following two messages provide support for sample names.

Sample Name Transmission

Note
The Sample Name Language Tag allows for future expansion regarding support for other languages. The default setting is zero, which defaults to English, and in this case the Name Data field is encoded using standard ASCII.

Sample Name Request

Extended Dump Header

This message gets around the 2MB sample size limit imposed by the SDS, whilst also providing extended precision and range for specifying the sample rate.

Loop types

In the descriptions below, 'forward' refers to playing samples in order from lower memory addresses to higher memory addresses, whilst 'backward' playback refers to playing samples in order from higher memory addresses to lower memory addresses.

Sample pointers appear in the order : Sample start, Loop start, Loop end, Sample end.

As with the above Loop Point Transmission and Loop Point Request messages, the following two messages overcome the single loop shortcoming of SDS, whilst additionally allowing longer loops to be specified. Here also, loop points can be modified without having to re-send the entire sample.

Extended Loop Point Transmission

Extended Loop Point Request

General System Information

Device Identity Request

This message is sent to request the identity of the receiving device.

Device Identity Reply

File Dump

This standard is similar to the Sample Dump Standard (SDS) but applies to file data rather than to sample data.

It comprises three similarly named messages (Dump Request, Dump Header and Data Packet), which as with the SDS are used in combination with the five Handshaking messages (EOF, ACK, NAK, Wait and Cancel) in accordance with the Dump Procedure.

File Dump Header

File Dump Data Packet

Encoding of data :

The 8-bit file data needs to be converted to 7-bit form, with the result that every 7 bytes of file data translates to 8 bytes in the MIDI stream.

For each group of 7 bytes (of file data) the top bit from each is used to construct an eighth byte, which is sent first. So :

becomes :

The final group may have less than 7 bytes, and is coded as follows (e.g. with 3 bytes in the final group) :

File Dump Request

MIDI Tuning Standard

This standard requires that each of the 128 MIDI note numbers can be tunable to any frequency within the instrument's range. Additionally it allows provision for up to 128 tuning programs.

An instrument which supports MIDI Tuning may have less than the full complement of tuning programs.

The specification provides a frequency resolution somewhat finer than one-hundredth of a cent, which should be fine enough for most needs. Instruments supporting MIDI Tuning need not necessarily provide this fine a resolution – the specification merely permits the transfer of tuning data at any resolution up to this limit.

See also the Real Time MIDI Tuning messages and Registered Parameter Numbers 3 (Select Tuning Program) and 4 (Select Tuning Bank).

Bulk Tuning Dump Request

Bulk Tuning Dump Reply

This message comprises frequency data in the 3-byte format outlined below, for all 128 MIDI note numbers, in sequence from note 0 (sent first) to note 127 (sent last).

Frequency data :

The 3-byte frequency data has the following format :

Where :

The frequency range starts at MIDI note 0, C = 8.1758 Hz, and extends above MIDI note 127, G = 12543.875 Hz. The first byte of the frequency data word specifies the nearest equal-tempered semitone below the required frequency. The remaining two bytes specify the fraction of 100 cents above the semitone at which the required frequency lies.

The frequency data of 7F 7F 7F has special significance, and indicates a no change situation. I.e. when an instrument receives these 3 bytes as frequency data, it should make no change to its stored frequency data for that MIDI key number.

General MIDI (GM)

Enable

Disable

Down-Loadable Sounds (DLS)

The Down-Loadable Sounds specification allows for the downloading of specific voice definitions (generally in the form of instrument wavetables), for situations which require certain voices to be available in specific locations which differ from other voice allocation modes (GM, GS, XG, etc.).

Enable

Disable

Notation Information

Bar Marker

If MIDI Clocks (F8) are also being sent, the bar number takes effect at the next received F8. If MTC but no MIDI Clocks are being sent, the bar number takes effect at the next received F1 (MTC Quarter Frame, System Common message).

Time Signature (immediate)

This and the following message each use the same data format as the Standard MIDI File Time Signature Meta Event (FF 58) with extra bytes on the end to handle compound time signatures.

Time Signature (delayed)

Device Control

These four messages each have a channel-based equivalent.

Master Volume

Master Balance

Master Fine Tuning

The total fine tuning displacement in cents from A440 for each MIDI channel is the summation of the displacement of this Master Fine Tuning and the displacement of the Channel Fine Tuning RPN.

Master Coarse Tuning

The total coarse tuning displacement in cents from A440 for each MIDI channel is the summation of the displacement of this Master Coarse Tuning and the displacement of the Channel Coarse Tuning RPN.

MTC Cueing

This essentially duplicates some of the Non Real Time MIDI Cueing messages, though without the time field, as the messages described here are intended to take effect immediately.

Cueing

MIDI Machine Control (MMC) Commands

'Single-byte' MMC Commands

These messages require no additional data beyond the command code (Sub ID#2) itself.

Locate / Go To

This message moves the receiving device's playhead to the specified SMPTE location.

Shuttle

This message provides bi-directional shuttling of the receiving device's playhead position.

MIDI Tuning Standard

See also the Non Real Time MIDI Tuning messages.

Single Note Tuning Change

This message enables retuning of individual MIDI note numbers to new frequencies in real time as a performance control. It also allows multiple changes to be made using a single message.

Note that if the note being retuned is currently sounding (within a tone generator), the note should be immediately retuned as it continues to sound with no glitching, re-triggering or other audible artifacts.

See also Registered Parameter Numbers 3 (Select Tuning Program) and 4 (Select Tuning Bank), which allow the selection of predefined tunings.

Frequency data :

The 3-byte frequency data has the following format :

Where :

The frequency range starts at MIDI note 0, C = 8.1758 Hz, and extends above MIDI note 127, G = 12543.875 Hz. The first byte of the frequency data word specifies the nearest equal-tempered semitone below the required frequency. The remaining two bytes specify the fraction of 100 cents above the semitone at which the required frequency lies.