Interface ConsoleProfile

The desk's separate DIRECT-OUT offer, when it differs from sendTaps. The Roland M-5000's direct out names four points — TOP OF CH, PRE PROC (our Pre-EQ), PRE FADER, POST FADER (Roland Support [19]) — where its aux send offers three. Absent means the direct out feeds from the same offer as a send, which is the openmixer case.

Appliance FORMAT gating (#176, archive §8, phase 1 slice — stereo/lcr only, no 5.1/7.1 yet): which BusFormats a bus TYPE may take on this appliance, narrowing BUS_TYPES' own allowedFormats — never widening it (same monotone-narrowing invariant every other cap on this interface holds). Absent ⇒ UNRESTRICTED: every bus type offers its full allowedFormats (the openmixer default). Keyed by BusAllocation's bus-type vocabulary (main, group, …) rather than ChannelKind — this module never imports that type (see the header note on why), and a format gate is a fact of the BUS TYPE, the same axis every other cap here narrows.

Default personality (skin) to pair with — orthogonal, user can override.

Which processing sections exist (the gate for tabs/panels).

WHICH of tapPoints a SEND may feed from, in signal order — the researched subset, per desk.

A skeleton and an offer are two questions. The skeleton is what the strip HAS; this is what the desk lets a send pick off, and real consoles offer less than they have: the Midas PRO aux is pre/post fader only, the Roland M-5000 family works {PRE EQ, PRE FADER, POST FADER} (M-480 Ref. p.56, console-profiles/roland-m5000.md §5). Every member must be a point tapPoints declares — console-profile.test.ts refuses a subset that names one it does not, because an offer of a point the desk has no capture for is exactly the over-declaration a client cannot detect.

It replaces the old ProfileSendTap string list, which spelled the same points in a SECOND vocabulary (preFader beside Pre-Fader) and had no reader anywhere in the console.

THE TAP POINT SET this desk exposes — its named feed points, in fixed signal order.

It is a property of the MODEL, which is the whole point: different desks have different points under different names, and that difference is data. The set is what the contract publishes and what a send's tap field is validated against, so a client renders the picker it was given and never assumes a constant.

Where the desk research lands

The SSL / Midas DigiPro / Roland tap-point studies drop in HERE — one TapPointSet per appliance, added to TAP_POINT_SETS and named on this field. No code moves. Until then every appliance declares OPENMIXER_TAP_POINTS, which is honest: it is the set this substrate captures, and claiming a point it cannot serve would be an over-declaration a client has no way to detect.

NOT a pair of sendTaps / directOutTaps string lists: those spell the same points in a SECOND vocabulary (preFader beside Pre-Fader), have no reader anywhere in the console, and cannot express an ORDER — three facts that make a field a comment.