Goal
Build a visual, strictly read-only UI for inspecting the complete configuration of a connected MIDI Fighter Twister.
Experience
Show the controller as a banked 4×4 knob grid. A user should be able to switch among all detected banks and inspect each encoder's:
- active, inactive, and detent colors
- rotary and push MIDI channel/number mappings
- switch action and movement mode
- indicator, detent, and super-knob settings
Also provide a global-settings view, device identity/firmware details, compatibility warnings, and access to the raw JSON export.
Safety boundary
This issue must not add configuration writes. The UI should call only the existing read-only discovery/export path, and the transport boundary should reject configuration pushes and all system/reset/bootloader commands. It should not rely only on disabled buttons for safety.
Acceptance criteria
Architecture question
Evaluate a small local web UI backed by the existing Node MIDI layer versus a packaged desktop shell. Prefer the smallest approach that preserves reliable SysEx access and the hard read-only boundary.
Goal
Build a visual, strictly read-only UI for inspecting the complete configuration of a connected MIDI Fighter Twister.
Experience
Show the controller as a banked 4×4 knob grid. A user should be able to switch among all detected banks and inspect each encoder's:
Also provide a global-settings view, device identity/firmware details, compatibility warnings, and access to the raw JSON export.
Safety boundary
This issue must not add configuration writes. The UI should call only the existing read-only discovery/export path, and the transport boundary should reject configuration pushes and all system/reset/bootloader commands. It should not rely only on disabled buttons for safety.
Acceptance criteria
Architecture question
Evaluate a small local web UI backed by the existing Node MIDI layer versus a packaged desktop shell. Prefer the smallest approach that preserves reliable SysEx access and the hard read-only boundary.