openmixerGitHub →

0006 — The channel strip is an ordered processor list; the fader is a processor

Status: Accepted (built for the insert chain) Date: 2026-06-29

Context

On a console, a channel strip has a fixed mental order — trim, polarity, gate, EQ, compressor, inserts, fader, more inserts, pan, out — and the operator cares deeply about where in that order things sit. Pre-fader versus post-fader sends and inserts are the classic example. Modelling pre/post as a boolean flag on each element forces a special case for every element and breaks down as soon as you want two post-fader inserts with a send between them.

Ardour/Mixbus and Non-Mixer both model the strip as a typed ordered list of processors where the fader is itself a processor in the list; Zynthian's chain model is the same idea. openmixer's design already stated this thesis.

Decision

A strip is an ordered array of processor nodes, and the fader is one of them. The fader's index defines the pre/post boundary, so pre/post is a position, not a flag — any insert, send, or crossover sits anywhere with no special-casing. Both LV2 inserts and built-in gain/meter/send nodes present the same minimal module shape (audio in/out, control ports, latency, bypass, position).

Built today: the per-strip insert chain is exactly this — an ordered list of LV2 slots reconciled positionally by planChain (ChainManager), where slot order is audio order and an unchanged prefix is never disturbed when you append. The full strip (with the fader and meter taps as ordered pseudo-modules, and pre/post sends interleaved) is the design extension of the same structure, landing with the PipeWire-native summing layer.

Consequences

  • Pre/post-fader inserts and sends fall out of ordering — no prefader boolean scattered through the model.
  • One reconcile algorithm handles "append an insert", "swap a plugin", and "reorder", because matching is positional and order is load-bearing.
  • The same module abstraction lets the engine compute per-element latency for telemetry (0013) and delay compensation.
  • The UI presents a console-shaped strip (not a raw node graph), compiled down to the ordered nodes underneath — keeping the declarative reconcile core (0005).
  • Fader and mute changes must ramp, never snap (a hard mute clicks); in a filter-chain linear/mixer node PipeWire's Props smoothing supplies the ramp for free.

Note — 2026-07-29: the ordered strip beyond inserts landed, in C

This ADR says the full ordered strip "is the design extension of the same structure, landing with the PipeWire-native summing layer". It landed — in the native engine rather than as filter-chain nodes (see ADR 0002's 2026-07-29 note), and the code names this ADR while doing it. the module doc comment in packages/pipewire-native/src/mix_order.h:

The mixer's `on_process` used to run the built-in stages in one hardcoded C
statement sequence (trim-gain → gate → EQ → comp → delay → reverb →
fader/sum, "fixed this phase, ADR 0006"). This header makes the REORDERABLE
middle — gate / EQ / comp / delay / reverb — DATA

So the fixed-order caveat this ADR records for the native stages no longer binds: the middle of the chain is reorderable, the fader's position is not.