User docs — Getting started
From nothing to one channel in the mix.
Everything below assumes a built checkout — see Get it if you have not built one yet. This chapter does one job: start the console, patch one real input, and hear it at MAIN. Once that works, the rest of the manual is about everything OpenMixer can do beyond it.
01
Start the console and the surface.
Two processes, two terminals. The server is the console — it owns the mix and needs no configuration file to come up. The surface is a plain web page; nothing about it is privileged over any other client that will later connect to the same server.
# From the top of a built checkout — see Get it if you have not built one yet.
pnpm --filter @openmixer/server exec openmixer-server
# In a second terminal, the surface:
pnpm --filter @openmixer/web-ui dev
The dev server prints the address to open — typically http://localhost:3000. The surface does not hardcode the console's address: it discovers the endpoint from the origin that served it, so the same build works from a phone on the same network without being rebuilt for it.
02
Check the header before you touch a fader.
Open the page. The connection indicator in the header says whether you are looking at the live console or the offline fallback — a simulated board the surface shows itself when no server answers, precisely so the controls can be learned with nothing behind them. If you expected a live desk and moving a fader does nothing, this is almost always the reason: check the indicator before assuming anything else is broken.
03
Patch a real input onto channel 1.
The channel roster already exists — a console's strip count is fixed at boot, and channel 1 is there whether or not anything feeds it. What it hears is a separate fact: open the patchbay and connect a real source — the first input of a plain USB interface is enough, a stagebox is not required — to channel 1's input. Nothing else needs creating first.
04
Bring the channel up and send it to MAIN.
On channel 1: make sure it is not muted, and bring the fader up towards unity. Every channel sums into MAIN by default, so there is no separate routing step for this — the meter on channel 1 and the meter on MAIN should move together as soon as there is signal on the patched input. If MAIN moves but you hear nothing, the fault is downstream of the console — MAIN's own output patch, or whatever MAIN is patched to.
05
Verify it without your ears, if you want to be sure.
The console is addressable by hand, on purpose. This reads the exact fader you just moved, straight from the server:
# From a third terminal, at any point — this is what "in the mix" means on the wire.
curl -s http://127.0.0.1:8080/api/channel/input/1/fader
position is the 0–1 value the fader cap sits at; db is what that position means in gain. Add ?watch=1 to follow it live instead of reading it once — the full address space is in the REST reference.
What's next
One channel works. Sixteen do the same thing.
Keep going in the manual
The surface
The header, the layout chips, the fader bay, and where to find things that are not where you would first look.
The channel strip
Signal order, trim, the tile controls, selecting and naming — everything you just did on channel 1, in full.
The patchbay and the graph
Crosspoint patching and multi-source channels, beyond the one input you just wired.
Sends, buses, groups and DCAs
Once one channel is in the mix, this is how a second one joins it without fighting the first for headroom.