REAC configuration

The transport reads its configuration from ~/.config/reac-pw/ — one file saying which NICs face REAC, and one file per segment beside it. reac-pw.service is the unit that reads them; it passes no interface, no rate and no role on its command line, so those files are the whole declaration. The mixer writes them; you rarely need to.

How it is normally written

Setup → Adapters → REAC in the mixer. Choose the interface and save, and the mixer declares the segment, writes its file and enables and starts the unit for you.

This is the supported path. It validates what you enter before it writes, which hand-editing does not.

The files

~/.config/reac-pw/reac-pw.env — the config-once fact, which NICs face REAC on this host:

# generated by openmixer — edits are overwritten
REAC_IFACES=enp3s0,enp4s0

~/.config/reac-pw/<iface>.env — one per segment, named for the interface that faces it:

# generated by openmixer — edits are overwritten
REAC_TX=enp3s0
REAC_ROLE=master
REAC_MIXER=m5000
REAC_RATE=96000
REAC_NAME=seg2

Field	Meaning
`REAC_IFACES`	Comma-separated interface names, exactly as `ip -br link` spells them. Each one declares a segment and names its file. A NIC that re-enumerates under a new name is a config change, and the daemon exits rather than serving a dead binding.
`REAC_TX`	The interface this segment transmits on. Normally the same as the one the file is named for; Setup writes them equal.
`REAC_ROLE`	`master` (this console owns the clock and drives the handshake) or `slave` (an external desk does). The launch role — read once, at start. Do not set it by hand: it is generated from the role you set on the segment, below.
`REAC_MIXER`	Which Roland desk the mixer presents itself as: `m200`, `m300` or `m5000`. Boxes lock to any of them.
`REAC_RATE`	The REAC wire pace in Hz — `44100`, `48000` or `96000`, one setting for the whole REAC side, and independent of `REAC_MIXER`: the mixer generation says which desk is impersonated, never the rate, and neither is ever derived from the other. `reac-pw` refuses any other rate outright.
`REAC_NAME`	This segment's name, which is the address the console's patches and its `/reac/segment/{name}` row use. A file with no `REAC_NAME` is the `default` segment. Changing it re-points every patch on that box.

There is no box model or label in any of these files. reac-pw learns which box is on a segment from the box itself and sizes and labels the nodes from that; the console's own expectation of which box should be there is a Setup field, stored with the adapter entry in adapters.yaml, and it reaches the transport nowhere.

The role is set in the mixer, not in the file

REAC_ROLE is generated. The operator's intent lives on the segment's own row, in the product's words:

curl -sX PATCH -H 'content-type: application/json' \
  -d '{"role":"mixer"}' http://console.local:8800/api/reac/segment/default

mixer is the master end of the desk↔stagebox pairing, recorder the slave end, and auto — the default — observes the wire and takes the end it leaves open. The console translates that into REAC_ROLE for every declared segment and writes it into the file the daemon launches from, so a daemon restart comes back as the end you asked for. auto launches as a slave: a slave transmits no master presence and so cannot collide with a desk already holding the wire, and auto then resolves for real on the segment's first announce.

The console never fights another master for the wire. When a rival master appears on a segment, the console classifies it: a desk is joined and the console takes the slave end; a stagebox whose switch is set to the wrong position is refused, and the refusal is shown as a named warning on the segment, so a misconfigured box can be corrected at the box rather than argued with.

The mixer only writes files it generated

The first line of every file the mixer writes is:

# generated by openmixer — edits are overwritten

A file without that line was written by a person, and the mixer leaves it exactly as it is — including its REAC_ROLE, which then keeps overriding whatever role you set in the mixer. It says so rather than doing it silently: a standing warning on /warnings, coded reac:config-not-generated, naming the file.

To hand the file over to the mixer, move yours aside:

mv ~/.config/reac-pw/enp3s0.env ~/.config/reac-pw/enp3s0.env.hand-written

The mixer generates a fresh one on its next projection and the warning clears. There is no button that does this, deliberately: a gesture that destroys your own file should be yours.

Verifying a change to the REAC or head-amp path

A soft meter is not proof anything changed at the box — see trusting what you see. Before and after any change that touches the transport, the enrolment path, or head-amp control, measure one channel on a box you are not experimenting on and confirm its reading did not move. Keep the same box, the same input, the same reference level every time, so a single number (a SENS ratio, an RMS level) is directly comparable across the change. If that reference channel moves, the change reached further than intended and the change stops, not the channel.

This matters most on a rig with more than one box: an experiment against one box's enrolment or clocking can, and has, silently perturbed a segment it was never meant to touch.

What is deliberately not here

No part of your rig is compiled into any package: interface names, MAC addresses, box tables, ports and paths are all configuration. If you find yourself wanting to patch a binary to change one of them, the setting exists somewhere and this is the wrong approach.

Checking

cat ~/.config/reac-pw/reac-pw.env ~/.config/reac-pw/*.env
systemctl --user status reac-pw
journalctl --user -u reac-pw -n 100 --no-pager
curl -s http://console.local:8800/api/warnings

If the box never establishes, work through the box is not establishing. The first suspects are always the interface (is it the right one, is it up, does it have an address it should not have) and whether something else on the segment is already acting as master.