The parameter bridge
The layer meant to map a knob, fader or OSC message onto a pinned parameter. It is built but not connected, so today you wire a controller in through the graph instead.
The parameter bridge is the piece that would take incoming MIDI, OSC, gamepad and DMX and land it on parameters you pin, without wiring anything. The model is in the codebase: a binding is one rule holding an incoming control, a target pinned parameter and a value range, and a pinned item can carry one binding per protocol at once.
None of it runs. The bridge that would open the ports and poll them is never started, the routine that would hand your saved bindings to it has no caller, and there is no interface for creating a MIDI or OSC binding in the first place. Treat this page as a description of an unfinished feature rather than a workflow.
What ships today
Pinning works. Collect the controls you perform with into the Pinned panel, and the panel saves in a companion file beside the project. See The Parameters panel & hotbar.
What you pin is what an export exposes. The Pinned panel is also the selection an export reads: the parameters on it become the controls a web page or the DNA Player offers whoever opens the piece, with no second list to keep in step. A pin that points inside a subgraph is skipped, because an exported control is addressed by a node in the top-level graph.
Keyboard binding works. A pinned parameter can take a hotbar key, which is a separate dispatch path from the bridge and is unaffected by any of the above. The hotbar is scope-aware and its bindings save with the panel.
Wiring a controller through the graph works, with limits. Drop the input node for your device, and connect its output to the parameter's pin. Serial, MQTT and Ableton Link deliver values this way today. MIDI, OSC, DMX and gamepad nodes do not: they read the same store the bridge would have filled, so they return their defaults. Inputs has the full breakdown of which sources reach the graph.
What the unfinished layer would do
Recorded here because the code and the saved format already carry it, not as instructions to follow.
A binding remaps the incoming number into a range you set, so a fader sweeping 0 to 127 can drive a blur from 0 to 50, or an angle from -180 to 180. Bindings live apart from the nodes, so one physical knob could be pointed at a different parameter without rewiring the graph.
OSC bindings match an address such as /synth/cutoff, and the matcher handles patterns: *, ?, character classes like [a-z], and alternations like {foo,bar}. A pin carrying an OSC binding with no address of its own falls back to /pinned/0, /pinned/1 and so on in pin order. That fallback is derived from the pin's position in the list, so removing or reordering pins silently re-points it.
MIDI learn exists as a mode in the live-input code, with a matching mode for gamepads, and neither has a button anywhere in the interface.
The Pinned panel already renders a binding read-out under a bound parameter, MIDI: CC 21 ch1 or OSC: /synth/cutoff, with (auto) after an address the app derived. Nothing can populate it.
OSC, MIDI, gamepad and DMX are desktop-only, and the Web Player has no audio output. A camera is the one live source a browser does carry. Design live-controlled pieces to run in DNA or the desktop The player.