MIDI: Difference between revisions

From NURDspace
No edit summary
Line 101: Line 101:
=== Serial MIDI (DIN) ===
=== Serial MIDI (DIN) ===


Unidirectional [https://en.wikipedia.org/wiki/8n1 8n1] asynchronous serial at 31.25 kbit/s ±1% (32 μs per bit, 320 μs per byte), no flow control. Physical layer is a current loop, with the output port driving an opto-isolator at the input port (max 5 mA) to avoid ground loops.
Unidirectional [https://en.wikipedia.org/wiki/8n1 8n1] asynchronous serial at 31.25 kbit/s ±1% (32 μs per bit, 320 μs per byte), no flow control. The unusual bitrate has the property of being convenient to generate from a 1 MHz clock. Physical layer is a current loop, with the output port driving an opto-isolator at the input port (max 5 mA) to avoid ground loops.


Cable contains a single shielded twisted pair, with the cable shield grounded by the output port only. Both ends use a 5-pin DIN connector, with pinout:
Cable contains a single shielded twisted pair, with the cable shield grounded by the output port only. Both ends use a 5-pin DIN connector, with pinout:
Line 109: Line 109:
  5  data-
  5  data-
  3  ''NC''
  3  ''NC''
The connector shield is ''not'' connected to the cable shield, cassis, or any other circuit or ground.
The connector shield is ''not'' connected to the cable shield, chassis, or any other circuit or ground.
 
Although a MIDI device may have only an input port or only an output port, most commonly it has both. A device that has an input port may optionally have a "thru" port, which is an output port which electrically repeats the input signal.
 
[http://www.personal.kent.edu/~sbirch/Music_Production/MP-II/MIDI/midi_physical_layer.htm This] page has some useful schematics and diagrams.


=== USB device class ===
=== USB device class ===

Revision as of 23:14, 15 November 2015

Protocol

MIDI is a stream of bytes requiring stateful decoding. Bytes are classified into:

00-7F   data bytes
80-FF   status bytes, subclassified into:
8n-En   channel messages (n = channel - 1)
F0-F7   system messages*
F8-FF   real-time messages

(* this use of the term slightly deviates from the standard, which includes real-time messages under "system messages", but the standard terminology is pointlessly verbose.)

Data bytes sent after power-on and excess data bytes after a system message should be ignored.

Real-time messages are isolated single-byte messages that can be interjected at any time without affecting the parser state (except FF which resets the state):

F8   MIDI clock tick, 6 per MIDI beat while playing
F9    reserved
FA   Start playing from song position 0
FB   Continue playing from current song position
FC   Stop playing
FD    reserved
FE   "Active sensing"
FF   Reset all state to power-on defaults.

System messages are not channel-specific.

F0 ...     SysEx message (manufacturer, variable data)
F1 xx      MTC quarter-frame (weird format)
F2 nn nn   Song position (MIDI beats)
F3 ss      Song select (song number)
F4 ...      reserved
F5 ...      reserved
F6         "Tune request", request oscillator calibration
F7         End of SysEx message

Channel messages encode the channel into the status byte, and are followed by one or two data bytes. Consecutive channel messages with the same status byte only need to send it once (this is known as "running status"). For example, a string of note-ons to channel 2 can be sent as 81 kk vv kk vv kk vv

8n kk vv   Note-on (key, velocity > 0)
8n kk 00   Note-off (key) without release-velocity info
9n kk vv   Note-off (key, velocity)
An kk pp   Aftertouch (key, pressure), aka "Key pressure"
Bn cc vv   Control change (controller, value)
Cn pp      "Program change" (program)
Dn pp      "Channel pressure" (pressure) = Aftertouch for all pressed keys
En xx xx   Pitch bend

Key 60 is C4 (central C), key 64 is typically tuned to 440 Hz.

Pitch bend is 14-bit unsigned little-endian. The center position is 0x2000 (encoded as 00 40).

Parsing

(WiP)

MIDI beat clock

MIDI beat = resolution of song position counter = 1/16th note = 1/4 of what most people would call a beat.

Six MIDI clock messages (ticks) are sent per MIDI beat during playback. The first tick after sending a Start or Continue message is the beat corresponding to the current song position and starts playback. When playback is stopped and continued, playback resumes from the song position counter, i.e. it repeats the most recent MIDI beat and continues from there.

The Start message is equivalent to song position 0 + Continue.

Setting the song position is not permitted during playback.

Example:

FA        start
F8        0.0
F8        0.1
F8        0.2
FC        stop
F2 03 00  song position 3
FB        continue
F8        3.0
FC        stop
FB        continue
F8        3.0
F8        3.1
F8        3.2
F8        3.3
F8        3.4
F8        3.5
F8        4.0
F8        4.1
F8        4.2
F8        4.3
F8        4.4
F8        4.5
FC        stop
FB        continue
F8        4.0
F8        4.1

MIDI time code

See wikipedia.

Transport

Serial MIDI (DIN)

Unidirectional 8n1 asynchronous serial at 31.25 kbit/s ±1% (32 μs per bit, 320 μs per byte), no flow control. The unusual bitrate has the property of being convenient to generate from a 1 MHz clock. Physical layer is a current loop, with the output port driving an opto-isolator at the input port (max 5 mA) to avoid ground loops.

Cable contains a single shielded twisted pair, with the cable shield grounded by the output port only. Both ends use a 5-pin DIN connector, with pinout:

1  NC
4  data+
2  cable shield
5  data-
3  NC

The connector shield is not connected to the cable shield, chassis, or any other circuit or ground.

Although a MIDI device may have only an input port or only an output port, most commonly it has both. A device that has an input port may optionally have a "thru" port, which is an output port which electrically repeats the input signal.

This page has some useful schematics and diagrams.

USB device class

Uses 32-bit packets containing the 4-bit "virtual cable" number, 4-bit packet type, and up to 3 bytes of data. MIDI messages other than SysEx are sent as single packets, while SysEx is split into 3-byte fragments (which may be interleaved with packets for other virtual cables). It is also possible to send raw MIDI data (e.g. to pass unparseable data unchanged), but only a single byte per packet. This is also used for real-time messages.

(j = virtual cable)

channel messages:
j8 8n kk vv   Note-on
j9 9n kk vv   Note-off
jA An kk vv   Aftertouch / Poly-KeyPress
jB Bn cc vv   Control change
jC Cn pp 00   Program change
jD Dn vv 00   Channel pressure
jE En vv vv   Pitch bend

system messages except sysex:
j5 Fx 00 00   single message, 1 byte
j2 Fx xx 00   single message, 2 bytes
j3 Fx xx xx   single message, 3 bytes

sysex message (including end-of-sysex byte):
j4 xx xx xx   non-final message fragment, 3 bytes
j5 xx 00 00   final message fragment, 1 byte
j6 xx xx 00   final message fragment, 2 bytes
j7 xx xx xx   final message fragment, 3 bytes

special messages:
jF xx 00 00   raw MIDI byte
j1 xx xx xx    reserved for cable events
j0 xx xx xx    reserved

Although in theory you can send multi-byte messages using multiple F-packets, not all devices will handle this correctly in practice. Conversely, although packet type 5 is officially not used for realtime messages, it seems prudent to accept it (but use F when transmitting them).

See class driver specification for more details.