Editor and librarian

A desktop application that edits the instrument's patch parameters over the same binary parameter plane the built-in UI uses. In progress; not yet released.

Editor showing the Oscillators section: rows of knobs, segmented selectors and toggles for oscillators 1 to 3, each labelled with its parameter name and tree path, some showing live values and a not-equal marker. — The Oscillators section in a live session. Every control is generated from the parameter model; the small text under each name is its path in the parameter tree. Values appear where the editor knows them, and the ≠ badge marks controls whose local value differs from the instrument's.

What it does

Full parameter surface. 265 parameters per timbre across oscillators, mixer and noise, filters, envelopes, LFOs, sequencer, voice and glide, timbre MIDI and global settings. The mod matrix and effects are not modelled yet.
Three timbres. The Synth 1/2/3 tabs rebind the whole surface; a parameter's wire id is its base id plus a fixed per-timbre offset.
Arm gate. Nothing reaches the instrument until the session is connected and armed. Disarmed edits stay in the local patch document.
Batched push. "Push all dirty" and "Push whole patch" pack records into blobs no larger than the instrument's own frontend sends.
Readback that never writes back. Changes made on the instrument's panel are observed and adopted into the editor without being echoed to the instrument.
Librarian. Capture a preset as it loads on the instrument, save it to a file, diff two patches.

Reading a control

Each control carries two small markers showing how much is known about it:

Marker	Meaning
Tier dot	How well the parameter's id and value mapping are established: value-proven (solid), order-proven (half), order-only (hollow).
Provenance dot	Where the displayed value came from: unknown, the panel, a preset, sent by the editor, or confirmed by readback.
`HW` badge	The id has been verified on hardware.
Dirty marker	The local value differs from what the instrument is believed to hold.

The kind of control follows the parameter's type: continuous values get a knob (cutoffs get a full-width slider), small enumerations get segmented buttons, booleans get a toggle. A continuous parameter whose range is not yet known is shown read-only and cannot be sent.

How it reaches the instrument

flowchart LR
  ED["Editor
desktop"]
  subgraph BOX["Instrument"]
    RL["Relay
whitelist + tap"]
    VC["Voice controller
UDP 7770"]
    FE["Built-in frontend"]
  end
  ED -->|"/x ,b records over LAN"| RL
  RL -->|"validated records"| VC
  FE -->|"/x ,b records"| VC
  RL -.->|"mirrored frames"| ED
  FE -.->|"sniffed"| RL

The voice controller is only reachable on the instrument's internal link, so a small relay runs on the instrument. It forwards only well-formed parameter records whose ids and types are in a generated whitelist, and mirrors the built-in frontend's traffic back for readback.

The relay runs from temporary storage and installs nothing. It can be restricted to datagrams from one configured source address.

State

Area	State
Parameter model, record encoding	DONE tested against captured traffic
Editable surface, arm gate, batched push	DONE against a mock voice controller
All wire types on real hardware	PENDING
Safe automation rate	PENDING default held at 50 Hz until measured
Mod matrix, effects	NOT MODELLED