Questions with straight answers.

No. Most software that looks like a mixer is a surface for a hardware console somewhere else. OpenMixer is the console: the audio runs through it. Inputs arrive from a stagebox or any PipeWire source, each channel has a fader and a processing chain, the buses are summed in the console’s own signal processing, and the mix goes back out to the PA.

There is no hardware desk in the signal path. Real consoles can be attached as controllers, but that is an optional side path.

Yes, and that is the design rather than a feature bolted on. One server holds the whole mix and every screen is a view of it, so a fader moved on the laptop at front of house moves on the tablet on the wing at the same time.

Every client is a remote client, including the one running on the same machine. There is no privileged surface.

No, and it is built on the assumption that it will not have one. The surface, the plugin catalog and the entire documentation set are served from the machine itself. Nothing is fetched from the network to draw a page.

GPL-3.0-or-later, and every package in the workspace carries the same licence.

Because there is only one correct number, and it is not a matter of taste. A stereo pair carrying centred mono content is the same signal on both legs, and summing two identical legs to one socket makes the result twice as loud in amplitude — six decibels hotter — than either leg on its own.

The fold applies a fixed −6 dB to undo exactly that doubling, so a centred mix lands at the same level folded as it was in stereo. A dial there would only let someone turn the correct answer into a wrong one.

Why the mono fold and the pan law are fixed numbers, not settings

It depends what is doubling. Two identical signals summed together double in amplitude, which is +6 dB. Two unrelated signals summed together double in power, which is +3 dB. Perceived loudness — what a listener actually hears — is a slower, more approximate curve: it takes roughly +10 dB before most people agree something sounds twice as loud.

All three are real and none of them is wrong; they answer different questions.

The three doublings

Amplitude is the size of the waveform itself — the voltage, the sample value — and it is what a fader multiplies. Power is proportional to amplitude squared, and it is what a meter of energy reads. Loudness is what a listener perceives, and it grows more slowly than either.

The decibel is the common ratio between all three: 20·log10 of a ratio for amplitude, 10·log10 for power, so a doubling of amplitude and a quadrupling of power both read as the same six decibels.

Power, amplitude and loudness

For the plugin hosts, yes: omx-clap-host and plugin-hostd are signed packages for Fedora and for Debian, Raspberry Pi OS and Zynthian, on x86_64 and ARM64.

The console itself is not published yet.

Install from our packages

Most likely solo in place. When the cue mode is SIP and something is soloed, every channel that is neither soloed nor solo-safe is silenced — that is what solo in place means, and it is the mode that silences the house rather than only the headphones.

The channel says so rather than leaving you to work it out: the mute state carries a separate flag for it, and the strip gets its own badge and dims like anything else that is not being heard — without the mute button pretending somebody pressed it. The way back is to clear the solo, or to make the strip solo-safe.

The other two holds read the same way: a mute group holding the channel, and a panic. Each is its own flag, owned by whatever set it.

Linux with PipeWire, Node 22 or newer, and pnpm to build. Audio comes from anything PipeWire can see, which includes a plain USB interface, so a stagebox is not required to try it.

The reference rig is a Roland REAC stagebox with an RME Babyface Pro as the clock master, on Fedora.

Because OpenMixer’s own timing comes from whatever hardware drives the audio graph, and it hands that timing to every stagebox as the REAC master. A professional interface with a phase-locked loop, the RME on the reference rig, keeps a steady clock and filters jitter; a free-running crystal drifts and a software timer jitters with the machine.

The REAC clock panel shows each segment’s pace source: phc or graph-ref means the rig is locked, free-run means it is not.

Clocking and sample rate

48 kHz and 96 kHz have both been run on the rig, including a change between them with the console live.

44.1 kHz has not been proven with a stagebox, and is not claimed. Proving it needs a real desk running at 44.1 to pace against.

No. The faders, EQ, gate, compressor, delay, reverb, buses and routing are all native to the console and need nothing installed.

A fresh machine has no LV2 plugins, so the plugin picker starts empty. That is expected, not a fault. Curated sets can be installed separately, tiered by measured round-trip latency so the live-safe choice is the default.

That is the offline mode, and the connection indicator in the header says so. With no server reachable, the surface falls back to a simulated board so the controls can be learned without a console behind them.

It is easy to miss precisely because it is not an error message. If you expected a live desk, the server is not reachable — check that it is running and that the surface is being served the endpoint you think it is.

Yes. The whole console is a REST surface: every entity answers GET, PATCH and OPTIONS at a plain, typeable address, and curl is a first-class client rather than a debugging trick.

OPTIONS on any entity publishes its contract — the writable fields, the ranges, the units and the enumerated options — so a client can be written against what the server says rather than against a copy of the rules.

Add ?watch=1 to any GET and it becomes a server-sent event stream that emits exactly what that GET returns, starting with a full snapshot.

For a whole surface, watch the root: one stream carries every committed change on the console. Prefer that to opening a stream per panel — browsers allow only six connections to an origin, and spending them all makes every later request queue.

No, and there will not be one. There is one door and one wire.

Under the console’s state directory — $XDG_STATE_HOME/openmixer/takes/<id>/, or ~/.local/state/openmixer/takes/<id>/ if that variable is not set, or wherever --state-dir points. Each track is its own file: one mono 32-bit float channel, WAV while it stays under 4 GB and RF64 once it does not, at the sample rate the graph was running when the take was recorded.

RF64 only changes the header once a file needs 64-bit sizes; any DAW that opens a WAV opens either form the same way.

Every patched input and MAIN, by default, with a per-channel opt-out — there is no channel list to fill in first. Aux and matrix channels are not armed unless you ask for them.

Each armed channel is captured at two points, simultaneously: its raw input, taken straight after the trim, and its post-fader signal. An input channel is offered a third point, pre-fader, and the points are a set rather than a choice — a channel can record pre and post fader at once. A bus master is offered post-fader only.

No control on the surface changes that set yet, so today a channel records its default unless something writes the field over the API.

No. A take’s channel set is fixed the moment it starts. Changing an arm setting mid-take affects the next take, not the one in progress — otherwise nobody could say afterwards what the first ten minutes of a show actually held.

Not yet. Arming is one channel at a time today. A wall-mode — tap tiles across the whole fader wall to arm or disarm them, with select-all and select-none — is designed, using the same mechanism sends-on-fader already has, but it is not built.

Yes — the print. MAIN is armed like every other strip, so the take already holds the mix you made on the night, and exporting writes that one capture out as a 24-bit WAV beside the stems. Nothing is summed to produce it: the stems are captured before the processing, so a sum of them would be the console’s inputs rather than the show.

Two limits worth knowing. It is WAV and not yet FLAC, which is the right depth in the wrong container for something that has to travel. And no button fires it yet — the export is served and works, but today it is fired over the API.

The stems themselves are never rewritten and there is no lossy stem export, because a mixer that recorded a show in a lesser format than it captured it would be throwing away the reason to have recorded at all.

No, and the take says so rather than hiding it. A channel that was armed but had nothing patched into it is skipped by the audio thread entirely, so its file is a header with no frames — and no frames were dropped, which is why the take honestly reports no drops at the same time. Emptiness and dropped frames are two different facts.

The take counts how many of its tracks are known empty, and separately how many it cannot speak for at all, because a take made before the console measured this carries no answer rather than a zero. At soundcheck, a channel whose track is empty is left on its live input instead of being switched to silence, and the console names which ones those were.

Loading a recorded take back into the live desk so it plays as if the band were on stage again. Load a take, engage it, and every channel with a matching track switches from its live input to that track — so you can set monitors, try a plugin chain or train an operator without anyone in the room performing.

A channel the take has nothing for stays on its live input; a soundcheck never replaces a working microphone with silence.

“nothing is listening to the take, so it would play unheard — engage a channel first, or check the take can serve these channels.” Play is a separate step from engage: engage is what switches channels from their live inputs over to the take’s tracks, and play only moves the transport.

Press engage first. If you did engage and still get this, the take has no track for any of the channels you engaged — check the take is the one you meant.

Play means hear it, which is why this refuses rather than obeying. A transport running to an empty room while the position number climbs is the kind of working control that wastes a soundcheck.

Yes. The live playback path still has no resampler, deliberately, so loading a take at another rate converts the tracks it will replay, offline, on disk, before the transport exists — the graph only ever opens files already at its own rate. The conversion is cached in the take, so a second load costs one file check.

A mismatch only refuses when conversion cannot happen: no converter built in, or a conversion that could not finish. That refusal still names both rates.

No. Recording and playback both use the one audio graph, and starting either while the other holds it refuses outright rather than queueing silently behind it.

Not yet. The path has taken its first real take on the rig — eighty-four tracks — which is more than it had, and it is not a show. Treat the feature as unfinished until one has been carried through it, the same way the features page already labels it.

The plugins on that rack add more delay than the place the signal is going can carry. The budget belongs to the destination, not to the plugin: a monitor destination is held to 5 ms and refuses; a program destination has 100 ms and an effects destination 60 ms, and those two let the edit through and warn instead.

The reason underneath names the plugin and the numbers — “ZaMaximX2 puts this chain at 7.4 ms — over the 5.0 ms budget for a monitor destination at 48000 Hz. On a monitor send the performer hears themself that late.”

Take out the plugin it names, replace it with a lower-latency one, or rack it somewhere the delay does not matter. Bypassing does not help: a bypassed plugin still costs its delay.

You racked a stereo plugin on a mono strip. The sentence names both ways out because both are real: most plugin families ship a mono build of the same processor, and a strip fed a stereo source can be made stereo.

It refuses rather than folding the plugin down because folding would be silent and wrong. Both output legs land in the strip’s one input port and are summed there — a measured 6.02 dB lift on the main mix from a stereo EQ sitting at unity, doing nothing. The mono twin of the same plugin moves the mix by 0.00 dB.

Nothing is written when it fires, and the whole rack is refused rather than quietly trimmed. Only the first plugin that does not fit is named.

You will meet it less often than you used to: the strip’s own rack door publishes what fits that strip, so the picker greys a plugin too wide for it instead of offering it. The refusal is still there for everything that does not go through the picker, and for a strip that changes width under a rack it already holds.

Post-Fader is a named point on the channel chain that does not carry audio yet. The slot is deliberately still there rather than tidied away, because a missing mechanism you can see is better than one that has quietly vanished.

Rack the plugin at one of the five points the sentence lists, or put it in the strip’s insert rack, which is after the fader anyway. When Post-Fader carries audio it joins the list and this stops firing, with no change needed to anything that talks to the console.

The sentence carries two numbers — how many slots the host has in all, and how many are held by plugins that were un-racked and never freed. When the second number is close to the first, that is the whole diagnosis: the host leaks a slot per un-rack, so a long session of trying plugins runs it dry.

Restart the plugin host. Nothing about the console’s own processing depends on it, so the desk keeps mixing while it comes back.

A mismatched take is usually converted for you: loading it resamples the tracks it will replay, offline, before you press engage, so play runs at the graph’s own rate. This refusal is what is left over — no converter built into this install, or a conversion that could not finish — and it still means the take cannot play here as it stands.

Set the graph to the take’s rate, or record a new take at the rate you are running.

A soundcheck is feeding the channels from a take, so recording now would capture that take back to disk rather than the room. Eject, then record.

It goes the other way too: “a take is being recorded — stop it before playing one back.” Both directions use the one audio graph and refuse rather than queueing silently behind each other.

Nothing is armed. Because arming is opt-out rather than opt-in, this almost always means nothing is patched — a channel with no source records nothing worth keeping and is left out of the derivation until something is patched into it.

Patch an input, or put back a channel you took out of the take. It refuses before the first sample rather than leaving you with a folder to clean up.

The recorder works out what the take needs to open safely and checks it first. The numbers are both there on purpose: “not enough space” is not something you can act on, and “it needs 14 GB and there is 3” is.

Free space or point the state directory somewhere with room. The same check guards a render and the print export, each with its own numbers.

The print is not a mixdown the console computes; it is the MAIN capture the take already holds. A take recorded with MAIN taken out of it has nothing to print.

Nothing can be done for that take. Leave MAIN armed — it is armed by default — and the next take will have one.

A channel config is a whole statement about a channel, so applying one to a channel that already holds something moves what is there. The console works out exactly which fields would move, refuses the apply, and hands the list back with the refusal — nothing is written.

Send it again saying confirm, and it applies. The list is the same list the dialog shows you, because the dialog is drawn from this refusal rather than from a preview the surface fetched for itself; a browser, an OSC surface and an MCP client all meet it and answer it the same way.

An apply that would move nothing is never held — applying the same config twice does not ask twice. And if you would rather not be asked at all, the sign-off is a console setting of its own, read afresh on every attempt. It is deliberately not the switch that arms destructive actions: an apply removes nothing.

The change you asked to take back has moved since — by another operator, by a control surface, or by a later gesture of your own. Writing the old value now would jump the fader from a value nobody expects to one nobody asked for.

Ctrl+Z gets the same sentence as the Undo this button in the list, and so does redo: the console compares the step against what the field reads now before it replays anything, and asks one question at all three doors rather than being careful in the list and blunt at the top of it. Nothing is written while the question stands.

The console asks instead of choosing: go back anyway, or leave it. A jump-back taken from a row in the list records in its new entry that it went over the later one, so the list says a jump-back happened. It never retries behind your back, and if the desk moves again while the question is on screen the offer is dropped rather than answered against a stale value.

One master per REAC segment is the protocol’s law, not a policy of this console’s. Another desk holds the wire, so the console is holding and has asserted nothing on it.

The panel offers the one gesture that resolves it: switch the segment to recorder and join the wire as the box end. Or take the other desk off the segment, at which point automatic picks it up on its own.

Two related sentences have no button, because the remedy is not the console’s to make. “A stagebox on this segment has its REAC Mode switch on M (master)” means walking to the box, setting the switch to S and power-cycling it. “Something is mastering this segment and the console cannot tell what it is” means finding out what else is on that wire.

The segment is following another desk, and a follower has no pace of its own to set — it locks to the master’s, physically.

If the rate is yours to choose, take the segment first: promote it to mixer, then set the rate on it. That is two confirmations rather than one, and each of them re-establishes the segment on the wire.

It has been mixing real shows on one rig since 2026-07-06, so the honest answer is that it depends on what your show needs.

Channels, buses, sends, DCAs, mute groups, EQ, dynamics, the analyser, feedback correction, delay alignment, plugin inserts and REAC stageboxes have all been driven and measured. The matrix does not carry audio yet, recording is unfinished, and no control surface has been verified on hardware. Read the known limitations before you commit to it, not afterwards.

By measuring audio. A control can read back perfectly and reach nothing at all, and a test that only asks the model whether it changed will agree with that forever.

So the signal processing is checked against values worked out on paper rather than captured from a run, graph changes are verified against the live graph rather than a model of it, and a phantom power claim needs a person at the connector rather than an indicator on a screen.

S-series boxes over REAC, including head-amp control — phantom, pad and sensitivity — which is what makes a box a stagebox rather than a stream. Two boxes have been established at once on the rig.

The REAC transport itself is a separate project, FreeREAC, and its own site covers what is known about the protocol and which boxes have been worked with.