Architecture

Development documentation: how openmixer is built, and why it is built that way. None of this is needed to run a desk — see the operator manual for that.

• Overview — the layered design: one canonical model driving a software mix engine plus hardware adapters, the server as the single source of truth, surfaces and windows as thin clients, pluggable I/O, C for the hot paths, a modular web UI.
• Technical manual — the monorepo packages, the canonical model, the software audio engine (PipeWire summing, mod-host inserts, pw-link reconcile, plugin-delay compensation), the control protocol, the graph-layout engine and the patchbay, and how to add an adapter, a plugin, a probe or a view module.
• Native DSP versus mod-host inserts — which processing is native and which is an LV2 insert, and why the two are never conflated.
• One summing bus — why MAIN, groups, auxes and matrices are all the same weighted-sum operation, the fader as MAIN's coefficient, and why the mono fold and the pan law's centre position are fixed numbers rather than settings.
• The row grammar and conformance — how every REST entity is built (mold, address codec, field codecs, station, registration), how a surface must derive from the contract instead of hardcoding it, and a sample of the conformance ratchets that hold both mechanically.
• Decision log — one architecture decision record per significant choice, with its context, the decision and its consequences.

The specifications and implementation plans these are built on are internal development material and are not published here.

Generated API reference

pnpm docs:api runs TypeDoc over the packages whose docstrings are rich enough to be worth generating from — declarations, core, server, audio-engine, catalog, patchbay, graph-layout, discovery, adapter-xtouch, adapter-midas, adapter-roland, adapter-x32, omx-ml and assistant — and writes static HTML to api-docs/ at the repo root. That directory is generated and git-ignored: it is not a second, hand-kept copy of the API, it is the existing TSDoc comments rendered. Build the dependency closure first (pnpm -r --filter "@freemixer/server..." build) so cross-package types resolve, then run pnpm docs:api. typedoc.json at the repo root is the one place the entry-point list is declared.

@freemixer/declarations is the page to read first. It holds every value the desk asserts about itself — travels, spans, counts, allowed values, declared defaults — each with the reasoning that fixed the number, and the generated reference is the only place that reasoning is readable without opening the source. Note what it is not: a surface may not import this package. The web UI does not list it as a dependency, so an import is a module-resolution error rather than a lint warning somebody suppresses, and declarations-withheld.test.ts in core gates core against re-exporting it. A surface learns these values at runtime from OPTIONS — OPTIONS /api/ for the row-wide ones, OPTIONS at an instance for the ones that belong to a device — or it draws nothing. Read the generated page to understand what the console publishes and why; derive from OPTIONS.