LiveSet · under the hood
The audio engine
Under LiveSet is a real-time audio engine written in Rust. It is built around one rule: once the audio starts, nothing on the audio path is allowed to stall it. This page is for the musician who wants to know how that is done, and why the set stays steady while you are editing it.
Why the audio thread does not stall
A real-time audio thread has one job and a deadline measured in milliseconds. So once the engine starts, four things never happen on it.
No allocation
After the engine starts, the audio thread never allocates memory. The render path never asks the operating system for more.
No waiting on the interface
Edits reach the engine through lock-free ring buffers, so the audio thread never waits on the interface to hand something over.
No system calls
It makes no system call on the audio path. There is nothing that can stall while the block is due.
No blast on a bad value
An out-of-range value becomes a silent no-op and never a burst of noise. A mistake goes quiet instead of loud.
So the interface talks to the engine over lock-free ring buffers. Edits and meters cross between the two without either side ever having to wait on the other.
A benchmark
How much of the budget a busy set uses
In a benchmark on an M4 at 48 kHz with a 1024-sample block, the engine has a 21.3 ms budget per block. A deliberately busy set: four decks, five effects on each, sixteen voices, sixty modulation routes, the master chain and the limiter, takes about 595 microseconds. That is roughly 2.8% of the budget, with the rest left as headroom.
The busy-case benchmark
device · M4, 48 kHz
block · 1024 samples = 21.3 ms budget
load · 4 decks · 5 FX each
· 16 voices · 60 mod routes
· master chain + limiter
cost · about 595 µs ≈ 2.8% of the budget
Buffers and latency
Buffer size and your interface
The block size is yours to set, 64, 128 or 256 samples, or down to 32 if your interface allows it. Smaller blocks tighten the response and ask more of the machine. Round-trip latency depends on the audio interface itself, so it is a figure your hardware sets and not one we can quote for you here.
The project file
The project file
A project is a single .liveset file: a human-readable, git-diffable RON document at schema version 6. You can open it in a text editor and follow it. You can track it in version control and see what changed between two takes.
Saves are atomic. So a crash mid-write does not leave you with a half-written project. Assets are referenced by relative path plus a checksum instead of baked in, so a set fits on a USB stick and travels with its samples. It is a plain document, the kind of thing you could still open and read in twenty years.
Sync and clock
Three ways to stay in sync, whether you lead the tempo or follow it.
Internal clock
The engine keeps its own time, steady and self-contained, for a set that runs on its own.
MIDI clock in and out
Follow another device or drive one. MIDI clock in and out, so LiveSet sits in a hardware chain either way.
Ableton Link
Share tempo across the network with other Link-aware software and apps on the same wifi.
What keeps it up mid-set
The work that goes into surviving a bad moment on stage.
Panics are caught
A panic on the audio path is caught before it can take the thread down. There is a soft-panic that fades and resumes, so a stumble need not be the end of the set.
NaN-safe setters
Its 134 setters clamp their values, with per-track auto-mute if something does go wrong on a track, so one bad number does not poison the whole mix.
Always-on 30-minute tape
A rolling capture of the post-limiter master is always running and always holds the last 30 minutes, so the moment you want back was being recorded before you knew you wanted it.
Degrade, do not blast
Where the engine has a choice between silence and noise it takes silence, and the out-of-range no-op above is the same rule applied at the level of a single sample.
Where it stands
"Never fails" is the goal.
We aim for an engine that does not fail on stage, and most of the work above is in service of that. It is a goal we hold ourselves to, and we cannot make it a guarantee while a misbehaving native plugin can still take the process down with it, because the plugin sandbox is written but not yet shipped. Until it is, the safest rig is one whose plugins you have run for hours at home.