Additional Explanations and Applications Notes

• Running Status
• Assignment of Note On/Off Commands
• Voice Assignment in Poly Mode
• "All Notes Off" Function When Switching Modes
• MIDI Merging and All Notes Off
• The Relationship Between the Hold Pedal and "All Notes Off"
• Further Description of Hold Pedal
• Priority of MIDI Receiving
• Release of Omni
• Continuous Controllers
• Basic Channel of a Sequencer
• Transposing

Running Status

Running status is a convenient short cut in transmission of data which saves time and makes it easier to minimize delays of transmitted MIDI data from the actual performance. With Running Status, after the first message, additional messages of the same type (i.e. Note On messages on the same MIDI channel) are sent without repeating the status byte for every message. Receivers must understand that if a data byte is received as the first byte of a message, the most recent, or "running' status is assumed.
For example, a note is normally played by transmitting a Note On Status Byte (90H) followed by the key number value (0kkkkkkk) and the velocity value bytes (0vvvvvvv). With Running Status, all additional notes on the same MIDI channel can be played by simply transmitting the key number and velocity bytes. As long as all following data consists of Note Ons on the same MIDI channel the Note On status byte need not be sent again.
Running Status is most useful for Note On and continuous controller messages. As notes can be turned off by sending a Note On with a velocity value of 0, long strings of note messages can be sent without sending a Status byte for each message. If the Note Off (8nH) message is used to turn notes off, a status byte must be sent.
The following is an example of Running Status. On the top is a complete data stream with one Status Byte for each pair of Data Bytes. Below that is a compressed data stream with only one Status Byte:

Figure 7 - Compressed data stream

While the above examples pertain to Note On messages, Running Status may also be used for all Mode and Control Change messages. Running Status can drastically reduce the amount of data sent by Continuous Controllers.
In some cases, the receiver must keep the status byte of the mode messages in a Running Status buffer even though the mode message is designated for a channel other than the receiver's basic channel. For example, if an Omni Off mode message is sent followed by Running Status Control Change messages, the Control Change messages can be properly recognized even though the Omni Off message may have been ignored.

Figure 8 - Running Status Buffer and Response of Receiver to Different Messages (Basic Channel: 3, Mode: Omni On)

The receiver should always hold the last status byte in a Running Status buffer in case the transmitter is utilizing Running Status to reduce the number of bytes sent. This also means the receiver has to determine how many data bytes (one or two) are associated with each message. It is recommended that the Running Status buffer be set up as follows:

1) Buffer is cleared at power up.

2) Buffer stores the status when a channel message is received.

3) Buffer is cleared when a System Exclusive or Common status message is received.

4) Nothing is done to the buffer during reception of real time messages.

5) The data bytes are ignored when the value of the status buffer is 0 (zero).

There are currently two undefined System Common status bytes (F4H and F5H). Should one of these undefined messages be received, it should be ignored and the running status buffer should be cleared. There are currently two undefined Real Time status bytes (F9H, FDH). Since these may convey only timing information, they should always be ignored, and the running status buffer should remain unaffected.
If Running Status is being used and a receiver is connected to a transmitter after the transmitter has powered on it will not play until the next Status byte is transmitted. For this reason it is recommended that the status be refreshed every few seconds.
To Summarize:

• a) A transmitter may or may not be programmed to take advantage of Running Status. Using Running Status, notes may be turned off by sending a Note On message with zero velocity . It is the responsibility of the receiver to always recognize both normal and running status modes.

• b) A receiver should take into consideration that a transmitter can send messages in either Running Status or normal modes. The following algorithm shows an example of an interrupt-driven routine:

  BEGIN

  Read Serial Input;

  IF bit 7 = 1 AND it is a Real-Time Message THEN EXIT;

  IF bit 7 = 1 AND it is not a Real-Time Message THEN

  BEGIN

  Store in Running Status Buffer;

  Clear Third Byte Flag;

  IF Tune Request THEN

  {=F6H}

  BEGIN

  Store it in FIFO;

  Increment Pointer +1;

  END

  ELSE {do not increment pointer here};

  EXIT;

  END;

  IF bit 7 = 0 AND Third Byte Flag = 1 THEN

  BEGIN

  Clear Third Byte Flag;

  Store Third Byte into FIFO;

  Increment Pointer +3;

  EXIT;

  END;

  IF bit 7 = 0 AND Third Byte Flag = 0 AND Running Status Buffer = 0 THEN

  BEGIN

  Ignore Data Byte;

  EXIT;

  END;

  IF bit 7 = 0 AND Third Byte Flag = 0 AND Running Status Buffer > 0 AND < C0H THEN

  BEGIN

  Set Third Byte Flag;

  Store Status into FIFO;

  Store Data Byte into FIFO;

  {do not increment pointer here};

  EXIT;

  END;

  IF bit 7 = 0 AND Third Byte Flag = 0 AND Running Status Buffer > 0 AND < E0H THEN

  BEGIN

  Store Status into FIFO;

  Store Data Byte into FIFO;

  Increment Pointer +2;

  EXIT;

  END;

  IF bit 7 = 0 AND Third Byte Flag = 0 AND Running Status Buffer > 0 AND < F0H THEN

  BEGIN

  Set Third Byte Flag;

  Store Status into FIFO;

  Store Data Byte into FIFO;

  {do not increment pointer here};

  EXIT;

  END;

  IF bit 7 = 0 AND Third Byte Flag = 0 AND Running Status Buffer = F2H THEN

  BEGIN

  Clear Running Status Buffer;

  Set Third Byte Flag;

  Store Status into FIFO;

  Store Data Byte into FIFO;

  {do not increment pointer here};

  EXIT;

  END;

  IF bit 7 = 0 AND Third Byte Flag = 0 AND Running Status Buffer = (F1H OR F3H) THEN

  BEGIN

  Clear Running Status Buffer;

  Store Status into FIFO;

  Store Data Byte into FIFO;

  Increment Pointer +2;

  EXIT;

  END;

  IF bit 7 = 0 AND Third Byte Flag = 0 AND Running Status Buffer ≥ F0H THEN

  BEGIN

  Clear Running Status Buffer;

  Ignore Status;

  EXIT;

  END;

  END;

If an instrument receives two or more Note On messages with the same key number and MIDI channel, it must make a determination of how to handle the additional Note Ons. It is up to the receiver as to whether the same voice or another voice will be sounded, or if the messages will be ignored. The transmitter, however, must send a corresponding Note Off message for every Note On sent. If the transmitter were to send only one Note Off message, and if the receiver in fact assigned the two Note On messages to different voices, then one note would linger. Since there is no harm or negative side effect in sending redundant Note Off messages this is the recommended practice.

Voice Assignment in Poly Mode

In Poly mode there are no particular rules which define how to assign voices when more than one Note On message is received and recognized. If more Note On messages are transmitted than the receiver is capable of playing, the receiver is free to use any method of dealing with this "overflow" situation (such as first vs. last note priority). The priority of voice assignments may follow the order in which Note On messages are received, the receiver's own keyboard control logic, or some other scheme.
When a transmitter sends Note On and Off information to a slave keyboard which is also being played, it is important for the receiver to distinguish the source of Note On/Off information. For example, a Note Off received from MIDI should not turn off a note that is being played on the slave keyboard. Conversely, releasing a key on the slave's keyboard should not turn off a note being received from MIDI.

"All Notes Off" Function When Switching Modes

When a receiver is switching between Omni On/Off and Poly or Mono modes, all notes should be turned off. This is to avoid any unexpected behavior when the instrument's mode is switched. Caution should be taken to turn off only those note events received from MIDI and not those played on the receiver's keyboard.

MIDI Merging and All Notes Off

A sequencer replays previously recorded messages and merges them with any messages received at its MIDI In. A MIDI merging device combines two incoming data streams in real time. In either case the result is that a single MIDI data stream is communicating information produced by more than one transmitter. If an All Notes Off messages is passed through either a sequencer or merging device, then all connected devices will shut off their notes, though the All Notes Off may have only been intended for the notes turned on by one specific instrument. When an All Notes Off is received by a sequencer it should check to make sure that it does not conflict with any notes currently being played. Similarly, if an All Notes Off message is contained in the recorded sequence, it should not be sent if Note On data for that channel is being received. A MIDI merging device should feature the ability to selectively filter All Notes Off messages to avoid this problem.
Mode messages with a second byte greater than 124 should be treated in the same way as the All Notes Off message since they also perform an All Notes Off function.

The Relationship Between the Hold Pedal and "All Notes Off"

If Note Off messages are received while the hold pedal (controller 64 (40H)) is 'on' they must be recognized but not acted upon until the release of the hold pedal. The same is true for the All Notes Off message. A Hold or Sustain pedal 'On' message takes priority over Note Off and All Notes Off until it is released.
All Notes Off should force voices to go to the release stage of the envelope, and not terminate the sound of the notes abruptly.

Figure 9 - The Relationship Between the Hold Pedal and "All Notes Off": MIDI Messages Transmitted

Further Description of Hold Pedal

Hold and Second Release switches use controller number 64 (40H). Proper implementation of the hold pedal will maintain the envelope's sustain level. A "Hold 2" switch has been defined as controller number 69 (45H) as a means of implementing all other hold functions (e.g. "freeze" where envelopes etc. are frozen in their current state) and/or for implementing two different hold functions simultaneously. "Chord Hold", which holds only the notes played while the foot pedal is on, is equivalent to the Sostenuto controller 66 (42H).

Priority of MIDI Receiving

An instrument capable of receiving and processing incoming MIDI data must give priority to its MIDI In port over its local functions such as the front panel or keyboard. It is critical that incoming data never be ignored or mishandled due to the processor's attention being elsewhere. At 31.25 Kbaud, one byte is sent every 320 microseconds, which means that proper handling of the received data during any long-term or ongoing MIDI communication will require a high speed microprocessor. For this reason, interrupts and FIFO (first in/first out) buffers are commonly used. As soon as possible after an interrupt is generated, received data can be stored in a FIFO buffer for processing later on. This data handling can take much less than 320 µS, allowing time for the microprocessor to handle other aspects of the instrument's operation.

Release of Omni

As a transmitter has no way of knowing what channel a receiver is on it is best to always be able to turn Omni off by means of front panel controls on an instrument.

Continuous Controllers

All controller number assignments are designated by agreement between the MMA and JMSC. The numbers listed in Table V are specified for standard musical instrument applications. However, many non-musical devices which implement MIDI, such as lighting controllers, may use designated controller numbers at their discretion. Due to the limited number of controller numbers it would be impossible to assign a number to every possible effect (musical and non-musical) used now and in the future. For this reason, controllers are generally assigned only for purposes associated with musical instruments. It is up to the manufacturer to inform their users of the fact that a device is using non-standard controller assignments. Though controllers may be used for non-musical applications, they must still be used in the format detailed in Table IV.
A manufacturer wishing to control a number of device-specific parameters over MIDI should used non-registered parameter numbers and the Data Entry controllers (Data Entry Slider, Increment, and Decrement messages) as opposed to a large number of controllers. This alleviates possible conflict with devices responding to the same control numbers unpredictably.

Basic Channel of a Sequencer

To a receiver, the output of a MIDI sequencer is identical to the output of any MIDI transmitter with the possible exception of added Real Time bytes. A transmitting instrument sends on a particular channel which a sequencer then records and re-transmits. Thus, a sequencer does not need a Basic Channel as do other instruments. However, this does not prevent a sequencer from having a Basic Channel for recognizing mode messages or changing channels.

Transposing

If key transpose is implemented on a keyboard instrument, the MIDI key number 60 can be assigned to a physical key other than middle C. Transposition is allowed on both transmitters and receivers. The transposing system in a device should separately affect the keyboard data and incoming MIDI data going to the voice module. To avoid confusion it is a good idea to use an indicator to show when key transpose is active.

[Index | Main Paragraph ]