MIDI notes

From Helpful
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)

MIDI buses

Serial MIDI

The classic, seen on thirty years of devices.

This is a fairly standard serial port, in one direction, sending octet packets, at 31250 (±1%) baud.


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 ~5mA comfortably much is more important than precise voltage.

...and 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 the max current your output pin can sink, which these days is rarely limiting).



MIDI cables may only have 3 wires, but might have 5.

This isn't relevant to standard uses of MIDI, since pins 1 and 3 are unconnected in sockets, on both ends.

There are non-standard devices that do use the extra pins, though.



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.
  • R1 is current-limiting resistor for the optocoupler's LED.
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), maybe check your optocouple specs
Simplified somewhat, drawn to clarify the "you're mainly just powering that LED through a long wire" view. Shows shield, and note that the IN side's socket will not connect that pin
they're in the original MIDI specs because, at the time, many things couldn't directly drive 5mA (and in those specs it's two triangles, because two inversions on e.g. a 74LS14 hex inverter ICs was a simple and cheap solution)
These days you're probably using a microcontroller, which tend to have buffers on each pin that can drive on the order of 30mA, so you could omit this
It's still not a bad idea (ease-of-repair-wise) to protect your IC by using a transistor, though. Keeping in that diode is smart for similar reasons.
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 devices, that is. The cable itself should connect it on both ends so that cable doesn't have a direction.
so the socket on the IN end should not connect the DIN barrel/pin 2





Plugging around devices

MIDI is one-directional.


In a chain, earlier device can talk (only) to any later devices, because that's the direction messages go.

Whether they listen to any particular regular sort of message depends mainly on the channel part of the message. (Which does not apply to things like SysEx.)


This means the order devices are hooked up in matters.

And you'ld generally put just-controllers earlier, just-synths at the end.

If more than one playable-and-controllable thing is involved (this includes PC DAWs), you have to think about it a little harder.


There are some footnotes to hardware's sockets. In particular, they may have:

  • MIDI IN - usually means it plays sounds in response to messages
  • MIDI THRU - a copy of of the IN plug (buffered but otherwise direct)
  • MIDI OUT - means it can be the origin of notes/messages



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).

On 3.5mm TRS

Slimmer devices started using 3.5mm (and sometimes 2.5mm) TRS plugs on the device, with adapters to 5-pin DIN.

These weren't all wired the same way, so MMA decided to set a standard.

https://www.midi.org/midi-articles/trs-specification-adopted-and-released


Type A (verify)

T - sink
R - source
S - ground

Type B

T - source
R - sink
S - ground


I've seen DIN-to-TRS boxes with a DPDT switch to support both.

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, mostly more portable devices.

I haven't yet found anything on conventions about polarity, or voltage (I've seen 5V and the occasional 12V). (Or even pins; some seem to use 1 and 2, or 3 and 2, even though using shield is not a great idea)


This is usually safe enough, because even if you plug that into another device, pin 1 and 3 tend to not be connected internally because they have no function.

Some MIDI cables don't even have wires on all pins (though most do(verify)).


That said, there are further non-standard uses for pins 1 and 3, which would conflict.



USB-MIDI

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 a field called 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 present in serial MIDI is basically absent here (though note it's not a realtime bus, so there are still some small footnotes to this).


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


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]

Bluetooth

Expect at least 3ms to 6ms of added latency(verify) and possibly more like 10 or 20ms, depending on bluetooth version and a few other practical details.

If it stays on the low end of that, that's good enough for many uses.


There are various DIY projects using Bluetooth BLE modules


RTP-MIDI

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)

RTP-MIDI / rtpMIDI (a.k.a. AppleMIDI, but it's open and unlicensed) is MIDI over RTP, with RTP typically on top of UDP(verify). (so has details like RTP doing automatic retransmission)

So this amounts to MIDI over Ethernet or WiFi.


On LAN, latency should be about as good as serial MIDI, and it can sometimes be a practical way to link many things together, and do so over a somewhat larger distance.

On WiFi you generally can't guarantee latency to always stays under an acceptable level (depending a bit on your environment, other users, etc), so best case it just works perfectly, worst case you can't even fix it.

Over the internet you'll have at least your broadband's latency, which is often on the order of ~7-10ms of latency, so this .


Note that latency jitter doesn't directly mean inaccuracy, see e.g. https://tools.ietf.org/html/rfc4696#section-6


OSX since Tiger (10.4) has RTP-MIDI. It's that thing called "Network" in the MIDI setup. It's also in iOS since 4.2 (so ~2010, iPhones around 3G)

Beyond that, the limited need, and the existence of things like it (like OSC), means it's not in widespread use, though there are implementations on many platforms, and a bunch of interesting DIY hardware it's being used on.

To get it elsewhere, see e.g. wikipedia's implementation list.


https://tools.ietf.org/html/rfc4696

Virtual MIDI devices

MIDI generally means a way in or out of the computer - application to device, or device to application.

Which does not cover the case of application to application, e.g. between DAWs or from midi-generating apps.


Virtual MIDI devices are basically something you can open as an in and out port, that does nothing more than repeat what it gets. That way, one app app can write to it, and another can read from it, and it works out as a virtual midi cable.


On windows, install something like loopMIDI

On OSX, adding a 'Virtual MIDI Cable' is what you want.

On linux,

on ALSA, look at snd-seq-dummy

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.


Devices can ignore a messy message and focus on a new one immediately, without any state, because the highest bit is set only in the start byte of a message, and additional bytes never do. (The only sort-of-exception is SysEx, which also ends with one, but still should not contain any)


Message types are conceptually subdivided like:

  • Channel Message
    • Channel Voice messages
      • Note On, Note Off, Aftertouch
      • also PitchBend, Control Change, Program Change (because it's related to voices)
    • 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 predefined universal ones)
Also used to implement some extensions, like MIDI Machine Control
Due to variable-length behaviour, these are terminated (so that implementations can properly ignore them)


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 value 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
1110cccc 0VVVVVVV 0VVVVVVV
were V is an unsigned 14-bit integer value (0..16384) (lowest 7 bits are sent first)
the halfway value 8192 means no pitch bend.
The amount of tone range that the extremes correspond to is chosen by the listening side
apparently often either two semitones(verify)
the sending side can choose a smaller range by using less of that fairly large integer range

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 footswitch, pedal, slider, etc (a usually-physical controller) changes
1011cccc 0CCCCCCC 0vvvvvvv
where C is controller number, and v is a value
controller number....
120 through 127 have functions like reset, mute, local control, omni on/off, poly on/off - and are considered channel mode messages, see below
0 through 101ish 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,38, 96,97, 98,99, 100,101 are involved in a more free-form extensible thing, including the RPN and NRPN extensions (which also allow 14-bit values)


  • ProgramChange
1100cccc 0nnnnnnn
change the instrument patch, basically the type of instrument
there is a list in General MIDI. Other synths tend to have their own
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


CCs

Control Change are intended as "send when a physical knob changes".

These were intended to alter parameters of a synth on a particular channel.


Since most synths listen to relatively few,

this is great for mapping knobs to arbitrary DAW functions
you can easily get away with picking a bunch of them for custom controllers
there's a bunch of semi-standards based on CCs - some of which conflict


RPN and NRPN
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)

Plain CCs are a well defined set of parameters, but most of them have a single function that you may not care about.

When playing with new parameters, there are at most three dozen (general-purpose or undefined) CC numbers you could get away with using for arbitrary mapping.


RPN and NRPN are essentially a simple protocol built on top of a few CCs, that sets parameters in a new, larger set.

In theory it allows for 14 bits of specifying parameters (so 16384 distinct ones), though in practice people seem to use just a few MSBs for distinct sets.


In some ways it's just a way to get more parameters - and you can still get them to conflict. (You could look to SysEx if you wanted something more exclusive)

(So, just like CCs, you may wish to do them per synth/channel)


RPN and NRPN use the same mechanism to set their parameters.

Whether you set RPN or NRPN is controlled by which CCs you start with:

NRPNs are sent via CC 99 (NRPN Most Significant Byte) CC 98 (NRPN Least Significant Byte)

RPNs are sent via CC 101 (RPN Most Significant Byte) and CC 100 (NRPN Least Significant Byte)


RPNs

There are only a few RPNs.

In MSB, LSB pairs:

  • (0,0): pitch bend range
  • (0,1): fine tuning
  • (0,2): coarse tuning
  • (127,127): RPN null / reset (clears the parameter being modified)

And apparently later(verify)

  • (0,3): Tuning Program Select
  • (0,4): Tuning Bank Select

And also:

  • (0,5) Modulation Depth Range (from GM2 specs)
  • (0,6) MPE Configurarion Message (from MPE specs)
  • (0x3D, 0 through 8): Three Dimensional Controllers


Example:

CC 101 - RPN parameter's Most Significant Byte
CC 100 - RPN parameter's Least Significant Byte
CC6 MSB value
CC38 LSB value (optional)


Since the last-selected parameter stays active

you can also send CC96 (data increment) and CC97 (data decrement) (verify)
it is considered good practice to do an RPN reset after you're done


NRPN

NRPNs are the same, but start with

CC 99 - NRPN parameter's Most Significant Byte
CC 98 - NRPN parameter's Least Significant Byte


The rest isn't standardized, and will have to come from manuals of the devices you have


There are some groups of definitions, such as

Yamaha XG
Rolands GS(verify)


https://www.midi.org/specifications-old/item/table-3-control-change-messages-data-bytes-2

Channel mode

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

Specifically:

120: All Sound Off
121: Reset All Controllers
122: Local Control
basically, local=off says "you, a keyboard+synth, should send notes to MIDI out instead of playing yourself (also still plays what it gets)" (verify)
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
and makes sense for some instruments, like guitar controllers


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

http://www.personal.kent.edu/~sbirch/Music_Production/MP-II/MIDI/midi_channel_modes_and_the_basic.htm



Some controllers and DAWs have a 'panic' button used for "argh I have no idea why you are still making sound (probably a missed noteoff?), please stop it".

This sends 123 and/or 120.
And sometimes also NoteOff for all notes, in case a sound producer doesn't understand 123 or 120.

System Messages

All 1111....

Divided into

System Common Messages (1111000 through 11110111)
SysEx (11110000 (data) 11110111)
System Real-Time Messages (1111000 through 11111111)
all single-byte, no data


There's time/song/tuning stuff is in both these sections, so there's no huge distinction except some scheduling detail (e.g. real-time messages may be sent during SysEx).

SysEx is used for a lot of stuff that fits nowhere else

e.g. device-specific interaction stuff (usually in the manual) that doesn't suit CCs
some parameter upload stuff (e.g. DX7 SysEx)

MIDI monitors may report all of this as SysEx, just because most of it's special-cased control stuff.


SysEx takes the form of

0xF0 (SysEx start)
Manufacturer ID (1 or 3 bytes), helps synths decide whether it should try to read the message [2]
a variable amount of bytes
0xF7 (SysEx end)

On timing, bandwidth, latency

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 is fixed at 31250 baud/second, slow by modern standards - yet not too bad, and was easy to implement at the time.

Sending a byte (counting start and stop bits) takes 320 microseconds.

Since common messages are one, two, or three bytes long (NoteOn and NoteOff are 3-byte), most things arrive in under 1 millisecond.


Yet wanting to send, say, ten 3-byte messages all at once means the last will by physically put on the wire ~10ms later.


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

  • Running Status skips the first byte of a message (the status) if it's the same as the last-sent message.
e.g. allowing shortening of a handful of NoteOns, or a bunch of CCs,
for example, three successive noteons might normally be
0x90 0x70 0x7F 0x90 0x71 0x7F 0x90 0x72 0x7F
but with running status be
0x90 0x70 0x7F 0x71 0x7F 0x72 0x7F
.
https://www.midikits.net/midi_analyser/running_status.htm
  • A running-status NoteOn with velocity 0 is one byte shorter than a NoteOff
since NoteOn with velocity 0 is understood as identical to a Noteoff by most synths anyway


This throughput limit rarely matters to human playing, because our timing is never robotically perfect, and saturating the bus with note messages would require playing so fast it wouldn't be musical.

However, it can start to matter with

MIDI sequencers, which may wish to send a bunch of things exactly on a beat
continuous change of pitch/modulation wheel, polyphonic aftertouch, or other fast CC
but an even slightly clever controller prioritizes note messages more, so this should not matter
The strongest argument (for something faster) may be Polyphonic Expression (altering parameters per played note), as that is currently often implemented assigning notes and their alterations on channels, round-robin.
that said, many of those are now USB-MIDI where it doesn't matter


In USB-MIDI, the data that is transmitted is almost entirely the same, but due to the way it is packed and the higher speeds involved, the latencies don't really add up anymore. (The latency of USB itself is still ~1ms, though, due to the way the OS handles it).



MIDI Sync and timing

Beat clock

For context:

Around music, sync refers to drum machines and sequencers communicating rhythm, or rather the pulse that a rhythm is based on. The earliest drum machines all used simple ad-hoc standards. Most were basic electronic pulses sent over a wire dedicated to it, but interpretation (mostly PPQN rate) varied, per brand and sometimes even model.


MIDI beat clock, a.k.a. beat clock or MIDI clock, is a more uniform standard by having it be part of MIDI, and be 24PPQN.


The MIDI message most central to beat clock is

0xF8 - MIDI Beat Clock, sent at a rate of 24PPQN


Note that MIDI clock doesn't trigger or alter any note, it's made purely to connect different devices that generate their own patterns, to keep them all in time via a master rate.

Such devices may well listen to related messages like

0xFA - Start
0xFB - Continue
0xFC - Stop


https://en.wikipedia.org/wiki/MIDI_beat_clock

MTC

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)

MIDI Time Code (MTC) is something like SMPTE timecode communicated over MIDI.

MTC is useful to synchronize things that are referenced in SMPTE (so wallclock-ish) time. (SMPTE timecode itself came from the wish to sync audio and video recorded separately, instead of having to do so manually e.g. using a clapperboard)


As such, MTC communicates hour, minute, second, frame, (and the rate - one of four rates, 24, 25, 29, or 30fps)


It was made with the idea of interfacing audiovisual equipment with MIDI, e.g. have a tape machines emit SMPTE so that synths would play along, and potentially play cued things, and have it be the source of cues.

It also lets you you show time (or bars and beats?) to people, which has potential uses while seeking in MIDI files.


You're more likely to see MTC emitted and/or consumed by DAWs.

It allows things like cueing between them (which beat clock can't do because there is no position information).


There are other potential uses, like triggering specific things at a specific time, playing videos synced to music[3].



http://midi.teragonaudio.com/tech/mtc.htm

Extensions

MCU and HUI

Mackie Control Universal (MCU) and Mackie HUI refers to physical controllers from the late nineties.

These controllers were originally specific to Logic. Later, other DAWS and other devices started speaking this protocol, for compatibility/feature reasons.


Why?

MIDI itself has a bunch of standard-enough control mappings, but they are mostly for synth parameters, not for common DAW controls, so if you want to use MIDI to control things like mixer volumes, record/play, mute, and such, you would need to spend a while mapping CCs - if the DAW even supported automating these controls yet.


MCU/HUI builds a protocol on top of MIDI. If both sides speak it, these DAW functions are controllable as soon as you plug it in, and in a way that doesn't clash with CCs.

It seems they talk both ways, so can also show information from the DAW.(verify)


MCU/HUI mostly uses SysEx messages.

While it was kept closed for years, it's now basically known, and there is decent documentation available e.g. in logic control, MIDI Implementation section.


MMC (MIDI Machine Control)

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)


MIDI Machine Control (MMC) is meant for control of physical media, including Play, Fast Forward, Rewind, Stop, Pause, and Record


Note that there are other start/stop mechanisms (like beat clock's, and some more custom ones) that are likelier to be used.


Implemented via SysEx, basically the sequence:

F0 Start byte
7F
xx Device ID, or 7F for 'all'
06 Denotes a MMC message
xx command
F7 Stop byte


Where command is one of

01 Stop
02 - Play
03 - Deferred Play
04 - Fast Forward
05 - Rewind
09 - Pause


e.g. a MMC Stop may be

 F0  7F  7F  06  01  F7


https://en.wikipedia.org/wiki/MIDI_Machine_Control

MSC (MIDI Show Control)

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)

Meant for things like cues and lighting.

Implemented via SysEx

https://en.wikipedia.org/wiki/MIDI_Show_Control

MVC (MIDI Visual Control)

MIDI Visual Control Specification.pdf

Fragmented notes on mapping

MIDI files

Other stuff

Octave numbering

Percussion

On note mapping

MIDI percussion means mapping a bunch of notes to specific percussion instruments (so yes, playing MIDI drums into a regular synths mostly gets you a few regular notes).

Most follow the General MIDI percussion list.

There are a few drum modules and DAWs that deviate. https://usermanuals.finalemusic.com/SongWriter2012Win/Content/PercussionMaps.htm


On NoteOff

Only NoteOn matters to the sound being made, and in various drum modules you can get away with not sending NoteOff at all.

However, DAWs may get confused if you don't send the according NoteOff before the next NoteOn (possibly because they try to do clever things with note lengths). Which matters when they're hosting the drum VST you want to use.


So just do send the NoteOff.

The easiest implementation would be to send it just before the next NoteOn, but that has a small effect on latency, so ideally you want to have sent it before that.

Because most drum modules ignore it, you can typically send the NoteOff immediately after the NoteOn(verify). If you want visible feedback of the notes in a DAW, it may be slightly nicer to send it some time later based on a timeout after the NoteOn.


On velocity

Given that 127 is the loudest hits, then perhaps 100 could be velocity, 50 is already ghost notes, and under 20-30 you may not hear anything.

General MIDI

SPMIDI

Scaled Polyphonic MIDI was targeted mainly at ringtones on simple mobile phones.

It allows SMF files to say how they should be simplified to play on devices that make only simpler sounds.


https://www.midi.org/specifications-old/item/scalable-polyphony-midi-sp-midi

MIDI software

MIDI hardware and DIY

More expression, and MPE

MIDI 2.0

MIDI and MIDI-like control from software

Lemur

initially a physical device, one of the earliest touchscreen devices, long dicontinued
now software by Liine
https://liine.net/en/products/lemur/

Touch OSC

scriptable in Lua
~20 bucks for a (device?) license
https://hexler.net/touchosc

Liine LiveControl 2

successor to Touch OSC
~25 bucks
https://liine.net/en/products/lemur/premium/livecontrol-2/

Open Stage Control

scriptable in Javascript (the entire thing is Electron(verify))
FOSS
https://openstagecontrol.ammd.net/


See also: OSC

See also

See also: