Ableton/Live/UG/40 MIDI Fact Sheet
- How Live handles MIDI timing, what can still go wrong outside Live, and tips for steady MIDI performance.
- A DAW handles MIDI in three situations, each with an ideal:
- Recording — notes and controllers from hardware such as a keyboard are stored, ideally with timing as exact as an audio recording.
- Playback — stored MIDI goes out to a hardware synth, or is turned into audio by an instrument such as Operator, ideally as an exact reproduction.
- Playthrough — MIDI from hardware passes through the DAW in real time to a synth or plug-in, ideally feeling as immediate as a piano.
- Two problems keep computer MIDI from the ideal:
- Latency — a constant delay. Audio has to be buffered on its way in and out of an interface. Players adapt to small delays as long as they stay the same; even a piano has some delay between key and string.
- Jitter — a random, varying delay. MIDI, audio and the interface run as separate processes with separate clocks, and moving events between them depends on the operating system and drivers. Jitter, far more than latency, makes timing feel loose.
- Ableton works from two assumptions: latency is better than jitter, because it is predictable, and when playing through while recording you want to record what you hear, even if that is slightly later than what you played.
- Recording — the MIDI interface driver timestamps each event on arrival, and Live places the event in the clip by that timestamp.
- Playthrough — Live delays events by a constant amount rather than playing them whenever the busy system gets to them. With monitoring on, it adds a delay based on the audio buffer size, so notes land in the clip where you heard them.
- Playback to hardware — Live sends timestamps for the driver to schedule outgoing events. Windows MME drivers cannot use timestamps, so Live schedules those events itself.
- During audio dropouts Live still receives and records MIDI correctly, even if playthrough sounds wrong; playback is accurate once the system recovers.
- Timestamps only exist inside the computer. External hardware acts on MIDI as soon as it arrives.
- MIDI cables are serial, so a chord's notes travel one after another; dense passages can smear timing.
- Older synths may scan their own keyboards slowly, adding jitter. Problems multiply as more devices join the chain.
- Live has to trust incoming timestamps and the handling of outgoing events, and can verify neither.
Tests and Results
- Input test: a MIDI source feeds a zero-latency splitter. One branch records into a MIDI clip; the other goes through a MIDI-to-audio converter into an audio clip. The offset between matching events measures Live's accuracy.
- Ableton tested three combined audio/MIDI interfaces, A, B and C, at about 50% CPU, on macOS and Windows, at 44.1 and 96 kHz and three buffer sizes: 36 configurations.
- Results: most jitter fell within ±1 ms on every interface. Worst cases ranged from ±4 ms (Windows, A) to ±10 ms (Windows, C at 44.1 kHz / 1024 samples) and ±11 ms (macOS, A and B at 44.1 kHz / 1152 samples). Interface C on macOS stayed within ±1 ms in every test.
- Output tests gave results comparable to input.
- Practices for the tightest MIDI timing:
- Use the smallest audio buffer your hardware allows, set on the Audio tab of Ableton/Settings.
- Use a good MIDI interface with current drivers, so timestamps are accurate.
- Turn track monitoring off when you listen to a hardware synth directly rather than through Live's External Instrument, and when recording MIDI generated by another device such as a drum machine. Monitoring adds latency to cover playthrough jitter, so use it only when actually playing through Live. See Ableton/Track/IO/Monitor/Off.
- Good hardware is the surest fix for MIDI timing problems; with it, any software MIDI system should behave well.
- With weaker hardware, Live still reduces jitter at the cost of a little added latency.
