Administrator guide

Everything a person responsible for the machine needs, as opposed to the person mixing on it. If you are setting a rig up for the first time, start with Installing openmixer; this section is the reference you come back to.

  • Services and units — the two systemd user units, what they run and how they depend on the session.
  • Ports — every port openmixer listens on, its default, and where the default is defined.
  • Configuration files — every file that changes behaviour, who owns it, and what survives an upgrade.
  • Environment variables — the complete reference for the server, and where the transport's own knobs are documented.
  • REAC configuration — ~/.config/reac-pw/, what Setup writes into it, and the fields it validates.
  • State and session directories — where sessions, scenes, patches, channel configs and settings live on disk.
  • Logs — where output goes and what to ask for when something is wrong.
  • Backing up sessions — what to copy, when, and how to restore.

The shape of the system

nginx :8880  ──  static web surface + reverse proxy
      │
      └──▶  openmixer-server  :8080  (REST + ?watch=1 SSE)
                   │
                   ├── PipeWire (the user's session graph)
                   ├── mod-host (LV2 plugin inserts)
                   └── reac-pw  ──  the REAC segment  ──  stagebox

Both openmixer processes are user units in the operator's session, because the engine is a native PipeWire client and must share the graph. nginx is an ordinary system service.

Precedence, once and for all

Every runtime parameter has exactly one default, defined in one place, and a documented override chain. For the network settings the order is:

persisted Setup value  >  CLI flag  >  environment variable  >  config file  >  built-in default

Persisted values live in <state-dir>/network-settings.json and are written by the surface's Setup → Network screen. This is why editing a unit file to add OPENMIXER_WEB_PORT may appear to do nothing: a persisted Setup value outranks it. The config file's web block is the bottom layer, for the same reason in reverse: it is the deployment's baseline, so a flag or a variable meant for one run still wins.