The MIDI Protocol

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:

9nkkvv
example:
90 3C 40
-----------------> time

where:

n

is the MIDI Channelrange: 0..F

kk

is a key pressed
range: 00..7F

vv

is a velocity with which the key was pressedrange: 00..7F

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:

8nkkvv
example:
80 3C 33
-----------------> time

where:

vv

is a velocity with which the key was releasedrange: 00..7F

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:

Program (instrument) change (2 bytes)

Pitch bend (2-3 bytes)

Control Change, ie pedal/footswitch (2-3 bytes)

Timing clock (1 byte)

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.

For example:

a MIDI device which does not recognise the 'velocity' value
in a note-on message, would play all notes at
the same volume, regardless of the velocity value.

MIDI Channels

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:

A keyboard typically sends messages on only one channel at a time.

A sequencer may send messages on any or all channels

A sound-module is usually capable of receiving messages on several
different channels at once.

Status Bytes and Data Bytes

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:

A Status Byterange: 0x80..FF

Zero or more Data Bytesrange: 0x00..7F

with the exception of System Exclusive messages, which have a

A Status Byte

Zero or more Data Bytes

an End-Of-Exclusive status byte.

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.

Types of MIDI messages

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:

Generally used for device-specific extensions to the MIDI protocol.
Each manufacturer is free to define their own System Exclusive Messages.
Sample Dump Standard messages, MIDI Time Control Full Message,
and other extensions are also implemented as System Exclusive messages

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:

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.

Unsupported MIDI Messages

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.

For example:

a device which does not recognise the Active Sensing message
should at least recognise that this message does not cancel the
current Running Status.

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.

Just because a device has received a
note-off message does not automatically imply that the note should
cease abruptly. Some sounds, such as organ and trumpet sounds will do so.
Others, such as piano and guitar sounds, will decay (fade-out) instead,
albeit more quickly after the note-off message is received.

A device which does not implement 'note-on velocity' must send
a note-on velocity of 0x40.
Similarly, a device which does not implement 'release velocity' must send
a release velocity of 0x40.
Such a device may use either a note-off/velocity=0x40 message,
or a note-on/velocity=0 message, though the latter is preferred, as it
allows Running Status to be used.