0011 — Faders are a 0..1 position plus dB, with a per-adapter scale

Status: Accepted (built) Date: 2026-06-29

Context

A fader value means different things on different desks. A Midas or X32 fader is already a normalised 0..1 control; a software gain is dB-native; an M-5000 has its own taper. The surface wants one consistent representation it can draw and the operator wants to see exact dB. If the canonical model committed to one device's units, every other adapter would have to lie.

Decision

The canonical FaderLevel is { position, db }: an opaque 0..1 surface position (1 = top of throw) with dB carried alongside as a derived read. The mapping between them — the taper — is owned by each adapter through a FaderScale (positionToDb / dbToPosition). The device-raw value never appears in the model; it stays private to the adapter.

NormalizedScale is the default (used by the Midas and X32 adapters, whose faders are already normalised). An adapter with a real measured taper supplies its own FaderScale without changing the model or the surface.

Consequences

• The surface draws and reasons in one unit (0..1) and shows dB next to it, identically for every device.
• A send is just a fader at an input × output intersection — same FaderLevel, same scale machinery, no separate type.
• Exact-dB entry (type a number into a fader) maps cleanly through dbToPosition, which the multi-modal input design relies on (0014).
• The dB shown for a normalised desk is an approximation over a generic throw until that desk's true taper is measured and supplied as a FaderScale — honest, and overridable per desk without churn.
• The web UI carries its own client-side taper (db.ts) for the demo/offline path; in live use the server-derived dB from the adapter's scale is authoritative.