Where examples of MIDI messages are presented, values are in hexadecimal
The MIDI protocol consists of 'messages' which are designed to allow synthesisers and sequencers to communitcate 'what sound to play' information.
Let's start with an example to illustrate a few concepts. Suppose the musician presses the middle-C key on a keyboard. The keyboard would send a 'note-on' message like this:
9n kk vv example: 90 3C 40 -----------------> timewhere:
So in the above example, the musician has pressed key '3C' (middle-C), with a velocity which is half-way along the range available velocities.
The MIDI device which receives this message will begin to sound the note middle-C, with the appropriate envelope et al for the device's capabilties and settings.
Now the musician releases the key, and a 'note-off' message is sent:
8n kk vv example: 80 3C 33 -----------------> timewhere:
In this case, the musician has released the middle-C key, a bit more slowly than it was pressed.
The receiving MIDI device will now either cease or decay, as appropriate, the note middle-C. (note 1)
Some other typical MIDI messages are:
As you can see, with only a few exceptions, MIDI messages tend to be very short.
MIDI Messages are all one-way. There are no 'acknowledgment' messages sent from the receiver back to the transmitter. This is an important point for the transmitter, because there is no guarantee that a given message is supported by the receiver.
A MIDI device will handle each message as best it can, or ignore it.
Notice how we have already introduced the concept of a MIDI Channel. There are 16 MIDI Channels, numbered 1 to 16, where the values n=0..F correspond to MIDI channels 1...16, respectively
All messages such as note-on and note-off are specific to a MIDI Channel. This gives us 16 independant control channels for controlling MIDI devices.
A single device may be capable of sending or receiving messages on more than one MIDI channel. For example:
Notice also how in our examples, the range of values for key (kk) and velocity (vv) is only 0...7f
This is because all MIDI messages have simple structure consisting of:
Status Bytes always have their Most Significant Bit set to 1, while Data Bytes have their Most Significant Bit set to 0.
As a general rule, when a MIDI device receives a new status byte, it takes on the appropriate state, regardless of whether the previous message was completed or not.
The only exception to this rule is System Real-Time messages, which may be inserted into the middle of other messages, without affecting those messages.
This basic structure of status and data bytes makes the MIDI protocol reasonably insensitve to single-bit errors in the data-stream.
MIDI messages which are specific to a MIDI Channel are referred to as Channel Messages. MIDI messages which affect the entire MIDI system (or at least entire MIDI device) are known as System Messages. System Messages are not associated with a MIDI channel.
Channel and System messages are further subdivided into the following classes:
In general, System Exclusive Messages are the only MIDI messages which are more than a few bytes long.
Since MIDI messages are sent and interpreted in real-time, quite some emphasis is placed on reducing the volume of data which must be sent.
For ordinary note-on and note-off messages, it is quite common for several notes to be turned on or off, more or less at the same time.
Consider the following example:
A musician presses a chord on a MIDI keyboard consisting of 3 notes, say a C-chord. Lets suppose that the keyboard is set to MIDI Channel 3. The following messages would result:
92 3C 44 92 40 40 92 43 3E ----------------------------------------------------> time status kk vv status kk vv status kk vv on,ch3 'C' on,ch3 'E' on,ch3 'G'
Notice how all the messages have exactly the same status-byte. Hence the status-byte is technically redundant for all but the 1st note-on message.
Running Status allows the subsequent MIDI messages to be sent without a status-byte. Only the data-bytes are sent.
In our example, the same messages could be sent as follows, using Running Status:
92 3C 44 40 40 43 3E ----------------------------------------------------> time status kk vv kk vv kk vv on,ch3 'C' 'E' 'G'
In order to extend the effectiveness of the Running Status concept, by definition, a note-on message of velocity=0 is interpreted as a note-off message of velocity=0x40.
Consider the following example:
The note middle-C is pressed, then released. Normally, this would result in something like the following messages:
92 3C 44 82 3C 40 ------------------ ~ -----------------------> time status kk vv status kk vv on,ch3 'C' off,ch3 'C'
The same messages could also be sent as follows:
92 3C 44 3C 00 ------------------ ~ -----------------------> time status kk vv kk 00 on,ch3 'C' 'C'
Note that this time, we have paid a price for making the message shorter. We have lost the ability to include a 'release velocity'.
We should bear in mind that not all MIDI devices are capable of generating a meaningful 'release velocity'. Such a device is likely to send a note-on/velocity=0 message instead of a note-off message, since it is required to send a release velocity of 0x40 in any case (note 2),
Also consider that it is somewhat uncommon for the release velocity to have any effect on the sound being generated. Most timbres (voices) which imitate 'real' instruments would be unaffected by the value of the release velocity.
A MIDI device is not required to implement all possible features described in the MIDI specification.
The MIDI specification does require that all MIDI devices be able to receive all possible MIDI messages without causing internal errors. (note 3)
If a MIDI device receives a message which corresponds to a feature which has not been implemented on this device, it is required to simply ignore this message.
This requirement extends to the correct operation of Running Status, which may be affected (or not) by messages which have not been implemented.
This is one of the strengths of the MIDI standard, as it allows simple and inexpensive MIDI devices to co-exist and interwork with more sophisticated MIDI devices.
physical_layer.html Contents midi_modes.html
Please note this Disclaimer