0014 — Touch, keyboard, mouse and surface are all first-class input

Status: Accepted (built for the web surface; hardware surface designed) Date: 2026-06-29

Context

The same mix is driven by an operator's finger on a stage-lit tablet, by a mouse and keyboard at a laptop, and — designed for S3 — by motor faders on an X-Touch. If any one of those is a second-class afterthought, the operator is forced into the others at the worst moment. A touch-only widget cannot be reached from the keyboard; a mouse-only readout is useless on a tablet; a control with no exact-value entry frustrates an operator who knows the dB they want.

Decision

Every control must be operable by touch, keyboard, mouse, and (designed) a hardware surface — none of them second-class. All four write to the one server (0003) and every surface re-renders from the broadcast, so they always agree.

  • Touch — large hit targets, generous spacing, drag faders/knobs, usable under stage light (high contrast). The live-gig view is designed touch-first.
  • Keyboard — full tab/arrow navigation with a visible focus ring; arrows fine-step, PageUp/Down coarse-step, Home/End jump to the ends, Enter snaps a fader to unity / a pan to centre / a knob to default; and exact-value entry where the operator wants a figure.
  • Mouse — pointer affordances, wheel to adjust, Shift for fine, double-click to reset-to-default.
  • Surface — MCU/X-Touch motor faders/encoders/scribble as bidirectional clients (planned as S3; built — packages/adapter-xtouch/).

Audio-domain conventions are honoured: a proper dB fader law (not linear), meter ballistics with peak-hold and clip, ramped mute (no click). Accessibility is not optional: ARIA roles and names on every control, keyboard-reachable, no touch-only or mouse-only widgets.

This is built in the web UI today: faders, knobs, pan, steppers, toggles and buttons each support pointer-capture drag, wheel (with Shift modifier), the full key set above, and double-click reset, and each carries a role="slider"/spinbutton/switch with an aria-valuetext in engineering units. The hardware-surface modality was the S3 design and is now built (see the 2026-07-29 note).

Consequences

  • The operator uses whatever is to hand without losing capability — finger, mouse, key, or fader.
  • It constrains every new control: it ships with keyboard handlers, wheel handling, an ARIA role, and a sensible reset, or it is not done. The pointer-capture pattern lets a drag continue when the pointer leaves the widget.
  • Continuously-changing meters are marked decorative (aria-hidden); the fader's dB readout is the accessible level surface, so screen readers are not spammed.
  • Exact-value entry leans on the per-adapter fader scale (0011) to convert a typed dB to a position.

Note — 2026-07-29: the hardware-surface modality is built

The module doc comment in packages/adapter-xtouch/src/index.ts — the Behringer X-Touch and X-Touch Mini "translating surface gestures into canonical ops and canonical state back into motor faders, LEDs, V-Pot rings, scribble strips and meters". It is the largest adapter in the repo. The decision — every modality is a first-class client of the same canonical intents, none privileged — is what let it drop in without a new control path.