MIDI notes

From Helpful
(Redirected from MIDI)
Jump to: navigation, search
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Serial MIDI

A relatively standard serial port, in one direction, sending octets, at 31250Hz (±1%).

The plug is the 180-degree 5-pin DIN variant (see also IEC 60130-9).

DIN pin numbering
(note that some pinout charts use their own numbering, so pay attention)
  • 1 NC
  • 2 Shield (disconnected on the receiving side)
  • 3 NC
  • 4 Source
  • 5 Sink

Each device connection (pin 4+5) is a 5mA current loop (rather than voltage-referenced), so being able to drive that much is more important than exact voltage.

In most devices you effectively drive the LED part of an optocoupler, so you mostly just need to add a reasonable resistor for the voltage you have (and considering the max current your IO pins can sink, which usually isn't limiting).

If making your own, note that optocouples vary somewhat in rise/fall time. Ideally it should be on the faster side, under a few microseconds.

MIDI cables may only have 3 wires, but might have 5. This should never be too relevant, since pins 1 and 3 are almost always unconnected, on both ends.

The three ports, roughly according to the MIDI spec

In the schematic on the right:

  • D1 is used to protect the optocouple from reverse polarity, but also from cable effects. Most any fast-switching diode will do.
it's a good idea for DIY, though could be omitted.
  • On the resistors:
R1 is current-limiting for the optocoupler's LED.
These resistors are frequently 220 Ohm but this doesn't matter very precisely
R2 is a current limiter and pullup(verify), and is often a higher value (0.5k .. 10kOhm), check your optocouple specs
  • The triangles indicate some sort of current buffer
they're in the original MIDI specs because many things at that time couldn't directly drive 5mA. (It's two triangles in that spec because two inversions via e.g. 74LS14 hex inverter ICs was a simple and cheap solution)
These days you're probably using am microcontroller, which tend to have buffers on each pin that can drive on the order of 30mA, so you can omit this
It's still not a bad idea (ease-of-repair-wise) to protect your IC by using a transistor, though. Same for the diode.
Then it's a good idea to use a resistor (here R4, R6) to limit the current through it.
  • cable shield should be connected only on the source side (avoids ground loops)
...within the devices, that is. The cable itself should connect it on both ends so that cable doesn't have a direction.
note that the DIN barrel should not be connected to the cable shield / pin 2

Simplified somewhat
(and showing wire shield)

This diagram should clarify the "you're mainly just powering that LED through a long wire" view.

Plugging around devices

MIDI is one-directional , in that any earlier device can play (only) any later device (selectively because communication has channels), because that's the direction messages go.

This means the order devices are hooked up in matters. And you'ld generally put just-controllers earlier, just-synths at the end, and think a little harder about the playable-and-controllable things in the middle (including a PC if involved).

Devices may have three different sockets:

  • MIDI IN - usually means it will play sound
  • MIDI OUT - usually means the device itself generates messages
  • MIDI THRU - a (output-buffered but otherwise direct) copy of of the IN plug.

While you can think up complex cases, most real-world cases are relatively simple, largely because of what each device is.

Note that THRU connections in series will slowly add timing errors (due to optocouple time), so if you have a house full of devices in a single long chain you may notice some latency from start to end. Few people will run into this, and you can reduce it by adding splitters early (building a tree instead of one long chain).

MIDI and power

MIDI does not carry power. (This also helps it avoid ground loops)

There are some devices that use pins 1 and 3 to provide power. I haven't yet found anything on conventions about polarity or voltage.

There is also the rare oddity that puts something else on pins 1 and 3. In theory that conflicts, but doing it wrong usually requires you to wire an output to an output, with a 5-wire cable, and chances are decent against you doing that.

Still, if you want this in your design, consider the slightly safer option of using a 7-pin DIN socket, because the extra two pins won't connect when inserting a standard 5-pin plug.

Byte protocol

Note that some of this focuses on the serial nature of the original serial implementation, and works a little differently in other variants.


Sending a byte (counting start and stop bits) takes 320 microseconds, and most messages take one, two, or three bytes, so most things arrive within 1ms.

Devices can resync easily because the first byte always has its first bit set, and additional bytes never do.

Message types are conceptually subdivided like:

  • Channel Message
    • Channel Voice messages - Note On, Note Off, and other voice triggering stuff
    • Channel Mode messages - say what the voices should do in response to voice messages (see more below)
...note that this is similar to ControlChange (which fall under Channel Voice)
  • System Message
    • System Real Time messages - meant for synchronization between MIDI devices (that support this, relatively few(verify)).
    • System Common messages - meant for all receivers, regardless of channel. Also used for some external hardware like tape (not seen very often).
    • System Exclusive (a.k.a. SysEx) messages
sent to a specific Manufacturer's ID
mostly to allow manufacturer-specific communication (though there are some predefine universal ones)
Also used to implement MIDI Machine Control
Due to variable-length behaviour, terminated with a specific package.

Channel voice

The most central in the music-making sense:

  • NoteOff
1000cccc 0nnnnnnn 0vvvvvvv
(note that NoteOn with a velocity of 0 is basically equivalent to a note off message)
  • NoteOn
1001cccc 0nnnnnnn 0vvvvvvv
where c refers to channel, n to note, and v t velocity
note is C0 to G10 (8Hz..12kHz) in semitone steps, so e.g. middle C is 60
e.g. an 88-key keyboard will use ~three quarters of the full 0..127 range
velocity of 64 is often used when there is no touch sensitivity
  • PitchBend
were V is an unsigned 14-bit integer value (0..16384), and the halfway value 8192 means no pitch bend.
(The actual amount of range in terms of tones is chosen by the listening side, often an octave by default(verify))

And perhaps

  • Aftertouch is further expression to playing notes.
Few instruments send it, few synths instruments listen to it, but it's nice to use when you have it (also, DAWs typically allow mapping it to something)
On keyboards (that have it) it is usually a force sensor that only does a thing when you lean harder into keys, and isn't particularly related to velocity. It's often also per-channel, i.e. there's just one sensor below all keys.
In some other cases (e.g. sensitive pads) it can be a more of a 'how softly you are letting go', and often also polyphonic (sent for each key, not per channel)
If sensed per key, it is sent in Polyphonic Key Pressure (1010cccc 0nnnnnnn 0vvvvvvv)
If sensed overall, it is sent in Channel Pressure (1101cccc 0vvvvvvv)

  • ControlChange is meant for when the state of a physical controller (footswitch, pedal, slider, etc) changes
1011cccc 0CCCCCCC 0vvvvvvv
where C is controller number, and v is a value
controller number....
0..101 mostly change how a synth behaves on a specific channel
some for specific controller types controller types (breath, foot)
many to specific synth parameters (portamento, soft, volume, balance, attack, sustain, release, brightness, detune, channel volume, other effect amount)
...except for pitch bend - which has its own message (see above)
6, 96, 97, 98, 99, 100, 101 are intended as a more free-form extensible thing
(including the RPN (Registered Parameter Numbers) extension)
120 through 127 have functions like reset, mute, local control, omni on/off, poly on/off - and are considered channel mode messages, see below

  • ProgramChange
1100cccc 0nnnnnnn
change the instrument patch. General Midi has a standard list, not all hardware need follow this.
this idea is extended by ControlChange 0, though it's less stanardized how
on some hardware (e.g. drum machines) it may have other functions

Channel mode

CC messages with controller numbers 120 .. 127 are considered Channel Mode Messages.


120: All Sound Off
121: Reset All Controllers
122: Local Control - basically, local=off lets you have a keyboard+synth that sends notes only to MIDI out, and only plays what it gets back.
123: All Notes Off - useful for sequencers, particularly in the context of omni and poly
124: Omni Off
125: Omni On
126: Mono (note: has a parameter)
127: Poly

Omni=on means messages received from all channels are played.

Mono means a new NoteOn should end the previous note

You may want this for portamento/glissando, in particular for things like guitar controllers so it can e.g. bend per string (=channel)

More specifically,

Mode 1 (Omni On, Poly) - from all channels
Mode 2 (Omni On, Mono) - from all channels, control one voice
Mode 3 (Omni Off, Poly) - from specific channel, to all voices
Mode 4 (Omni Off, Mono) - from specific channel, to specific voices


System Messages

All 1111....

Divided into

System Real-Time Messages
System Common Messages

Used for time positioning, clocks, reset, that sort of thing.

Perhaps most interestingly SysEx, e.g. used for data transfers by specific devices

On timing

Keep in mind that if a sequencer sends things on a beat, then having many notes parameters can add up.

With ~1ms of sending time per 3-byte message, just a few fingers' worth of notes is not perceptably late, though with many notes, continuous change of modulation wheel, polyphonic aftertouch, it more esily adds up to >10ms and start to become perceptible.

In this regard, USB-MIDI (which due to much higher packet speed doesn't have this pileup issue) is a nice thing, even if routing on your PC is a bit more abstract.

There are a few tricks to alleviate this delay on serial MIDI, including but not limited to:

  • Running Status skips the first byte of a message if it's the same as the last.
e.g. allowing shortening of a handful of NoteOn or a bunch of CCs,
  • A Running-Status NoteOn with velocity 0 is one byte shorter than a NoteOff


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

USB-MIDI protocol is mostly modelled on serial MIDI packets, though it adds a few things, like Cable Number, mostly for ease of routing(verify).

Since the transfer rate of USB is much higher (and devices are connected individually anyway), the timing pileup serial MIDI has is basically absent (though note it's not a realtime bus, so there are still some footnotes to this).

While USB-to-DIN controllers may work as before, distinct devices connected via USB-MIDI appear as distinct controllers (with one device on them), so there's more focus on routing within the host (usually a PC).

USB-MIDI is part of the USB standard, which means PCs support it easily, but more interestingly, that relatively simple simple USB devices and hosts can speak it.

For example, an arduino with USB host shield can talk to USB-MIDI keyboards/pads with little code.

It also makes interconnecting less universal than DIN-to-DIN, as you now need a PC -- or something else designed for this interchange, like a USB midi host. There are also Raspberry Pi / Arduino style solutions. [1]

MIDI Sync and timing

Beat clock


See also

See also:

Other stuff


Mackie Control Universal (MCU) and Mackie's HUI and (also audio IO) refers to a physical controller for DAWs, originally from the late ninties and originally specific to Logic.

These days there are many alternatives to such devices, often with their own (also often proprietary) protocols

MCU/HUI is for a large part just a specific convention on top of MIDI. The point of this is mostly to have a standard for all the things it wanted, rather than having to manually mapping every CCs to specific controls before anything much worked.

Other DAWs and devices have chosen to support this for compatibility/feature reasons.

General MIDI


Scaled Polyphonic MIDI allows SMF files to say how things should be simplified for non-musical devices that cannot make very complex sounds.

It was targetd mainly at ringtones on simpler/earlier mobile phones.


MIDI software

MIDI hardware and DIY

More expression, and MPE

MIDI 2.0

See also