The DSP-ownership role of a south-side adapter (the client/server axis of the I/O +
control architecture — see an internal spec §3).
Orthogonal to the I/O transport:
'server' — openmixer owns the DSP. The adapter is an engine (the software
PipeWire mixer, the mock) with full insert freedom: any hosted plugin can sit on any
strip. REAC/AES67 endpoints feeding such an engine are I/O only — the desk is ours.
'client' — a remote desk owns the DSP (Midas / X32 / Roland over OSC). openmixer
is a remote controller: processing is whatever the desk reports via detectTopology(),
and openmixer-hosted plugin inserts are off the table (a desk channel can have EQ — the
desk's own — but never an openmixer-hosted LV2/LADSPA insert).
Terminology note: in the Midas tooling, "marmaserver" names the DESK as DSP authority —
i.e. a 'client'-role adapter here. Do not conflate that "server" with this one.
The DSP-ownership role of a south-side adapter (the client/server axis of the I/O + control architecture — see
an internal spec§3). Orthogonal to the I/O transport:'server'— openmixer owns the DSP. The adapter is an engine (the software PipeWire mixer, the mock) with full insert freedom: any hosted plugin can sit on any strip. REAC/AES67 endpoints feeding such an engine are I/O only — the desk is ours.'client'— a remote desk owns the DSP (Midas / X32 / Roland over OSC). openmixer is a remote controller: processing is whatever the desk reports viadetectTopology(), and openmixer-hosted plugin inserts are off the table (a desk channel can have EQ — the desk's own — but never an openmixer-hosted LV2/LADSPA insert).Terminology note: in the Midas tooling, "marmaserver" names the DESK as DSP authority — i.e. a
'client'-role adapter here. Do not conflate that "server" with this one.