13 — MVP & UX Concept

Product scope and interaction requirements for the first playable Auvra. The canonical view and hardware-control architecture is in 15; visual implementation belongs to 14.

Status · reconciled 2026-08-30. The Mac MVP and software milestones M1–M5 are implemented. This document states product behavior, not implementation chronology. Project-wide status lives in 10.

1. MVP definition

Decisions:

• UI framework: egui, themed for a native Auvra look (14-ui-framework.md).
• Vehicle: the Phase-1 macOS app (11) — real engine, window standing in for the touch panel, any class-compliant MIDI keyboard as the keybed. Everything carries over to the S90 build unchanged (same engine, same UI, backend swap).
• Audience: a single user — the project’s own musician. Dogfooding quality bar: reliable enough for a rehearsal, not polished for strangers.
• Stance: performance first. The MVP optimizes for load patches, layer/ split, mix, play live, tweak a few controls. Deep sound design happens inside plugins on a DAW/desktop for now — Auvra edits performance parameters, not synthesis architectures.

In the MVP	Explicitly out
CLAP hosting of real instruments and effects; diagnostic built-ins	Plugin store (sideload folder instead)
Native CLAP editor workbench; touch-first macros for performance	VST3/LV2 backends
Unlimited slots, key/velocity zones, transpose	Native UMP I/O and MIDI-CI
Fixed-topology mixer (4 inserts, 2 FX buses, master + limiter)	Production control-surface hardware
Patches + setlists persist; switch with release-tail handover	OTA, multi-user, companion apps
PERFORM / MIXER / SETTINGS plus BROWSE overlay	Store service and community maps
Per-patch performance controls (see §4)	On-stage sound-design editing

2. Design principles

1. Stage rules: every core action (next patch, mute a layer, grab a control) is reachable within one gesture from PERFORM.
2. Never block the sound: UI actions must not glitch audio; destructive actions (delete patch) need confirmation, nothing else does.
3. The patch is the unit of thought. Players think in songs/patches, not in plugins. Plugins are ingredients, visible only when editing.
4. Text entry is a last resort. Auto-names everywhere (P23 · Piano+Pad); renaming exists but is never required mid-flow.
5. One screen = one job. No nested modes deeper than PERFORM → EDIT.

3. Screens & navigation

There are exactly three top-level views. 15 is canonical for their layout and the focused-slot interaction model.

flowchart LR
    HEADER["Persistent header<br/>patch · setlist · meters"]
    PERFORM["PERFORM<br/>focused-slot controls"]
    MIXER["MIXER<br/>slots · zones · routing · FX"]
    SETTINGS["SETTINGS<br/>audio · MIDI · hardware profile"]
    BROWSE["BROWSE overlay<br/>patches · setlists"]
    HEADER --> PERFORM
    HEADER --> MIXER
    HEADER --> SETTINGS
    HEADER --> BROWSE

PERFORM is the boot target and live control surface. MIXER owns patch structure, slot focus, zones, levels and effects. SETTINGS owns devices and hardware profiles. BROWSE is a header-invoked overlay, not a fourth view. Deep plugin editing uses the desktop native editor described in 16.

4. Accessing & controlling plugins

Three ways a musician interacts with a slot’s plugin: its parameters (the performance path, §4.1–4.2), its own GUI (deep editing on desktop, §4.3), and choosing which plugin fills the slot (§4.4).

4.1 The three-layer parameter model

Decision: nobody curates “all plugins on the market” — curation is layered and each layer already has an owner.

Layer	Owner	What it is	MVP
1 · Performance controls	The patch (i.e. the player)	Each slot exposes 8 assignable controls. Assign any parameter of the slot’s plugin (or its inserts) to any of them; stored in the patch. This is what’s on stage.	Yes — the primary UX
2 · Remote-control pages	The plugin author	CLAP’s stable remote-controls extension: plugins ship author-curated pages of 8 controls (main/filter/env/…).1 Browsable in EDIT; seeds layer 1 on first load (page 1 → the 8 slots).	Yes (read-only browse + seeding)
3 · Full parameter list	Generated	Grouped by the plugin’s param module paths, searchable. The escape hatch for assigning anything; not a stage surface.	Yes (as picker for layer 1)
4 · Community control maps	Store, later	Optional store-shipped maps for plugins lacking remote-controls. Crowd-sourced, not platform-curated.	No

Seeding order for a freshly loaded plugin: remote-controls page 1 → else the first 8 automatable parameters → else empty. The player then edits assignments in EDIT (long-press a control → picker over layers 2/3).

This answers the curation question structurally: plugin authors curate their own (layer 2), the musician curates per patch (layer 1 — the one that matters live), generation covers the rest (layer 3), and the market-wide problem becomes an optional community layer (4) instead of a platform obligation.

4.2 Implemented performance path

The three-layer model is implemented for the Mac/touch MVP:

• Command::SetSlotParam changes a live plugin parameter through the RT-safe command ring; CLAP receives the corresponding parameter event.
• A restored plugin’s first remote-controls page seeds up to eight focused-slot controls. The generated full parameter list remains the assignment fallback.
• PERFORM renders these as touchable knobs. Secondary-click or long-press opens the parameter picker; MIDI learn binds the next CC.
• Assignments persist in SlotSpec.controls and are cleared when the slot’s plugin changes, because parameter ids are plugin-scoped.
• Slot selection is banked/wrapped, so every active slot remains reachable.

M6 adds the hardware-independent control model and physical profile/feedback path defined in 15. It reuses these parameter commands rather than introducing a second performance-control system.

4.3 The plugin’s own GUI

Native CLAP editors are a patch-design workbench, not the on-stage surface. macOS embedding is implemented using a UI-thread-owned edit instance; Linux/X11 target validation remains open. 16 is canonical for ownership, embedding and platform constraints.

4.4 Selecting a plugin for a slot

MIXER opens a touch-first full-screen picker from the slot or insert being edited. It scans standard CLAP locations, shows descriptor/vendor metadata, supports search and persists the exact plugin id. The same picker pattern covers instruments and effects; BROWSE remains dedicated to patches and setlists.

5. MVP control surface (no hardware yet)

• On the Mac, PERFORM/MIX widgets are mouse/touch-operated; MIDI CCs from the connected keyboard can be mapped to layer-1 controls (simple MIDI learn) — that is the performance-control path until the S90 surface exists, and it exercises the same mapping model auvra-ctld will feed.
• The Phase-2 sim (11 §3) can inject control changes for automated UI testing, but is not required for the MVP.

6. Rehearsal acceptance scenario

1. Boot to PERFORM in < 3 s (app start on the Mac).
2. Create a patch with real CLAP instruments: a full-range lead/pad and a lower-key split.
3. MIX: balance the three strips, reverb send on the pad, limiter confirmed on master.
4. In PERFORM, verify seeded controls; reassign one to filter cutoff via the full parameter picker and MIDI-learn it to the mod wheel.
5. Save (auto-name), duplicate, tweak, save as second patch; both into a setlist.
6. Play; switch patches mid-sustain → previous pad tail rings out (release-tail handover), next patch playable < 100 ms.
7. Trigger a contained plugin panic and a supervised hard crash; unaffected audio survives the former and the journaled patch recovers from the latter.
8. Quit, relaunch: setlist, patches, assignments all intact.

The Mac MVP satisfies this flow in code; repeat it with the selected plugin set before releases and on the N100 during M6.

7. Milestone mapping

The M1–M6 ladder (12 §8) gains UI increments; engine scope is unchanged:

Milestone	UI outcome	Status
M1–M2	Debug HUD and RT command/telemetry wiring	Done
M3	PERFORM controls, CLAP discovery and plugin picker	Done
M4	Slot focus, zones and mixer banks	Done
M5	BROWSE, setlists, persistence and MIDI learn	Done
M6	Physical controls/feedback and the same UI on target	Active

8. Open questions [verify]

1. remote-controls and parameter-metadata quality in Dexed/Odin2 and the intended commercial plugin set. Surge XT is verified: 775 parameters and five curated pages, including an eight-control macro page.
2. Touch knob interaction — test vertical drag and detents on the real panel in P3; keep widgets abstract until then.
3. Text entry inside native plugin editors on a touch-only target.
4. Per-slot level meters at high slot counts — rendering cost on the target GPU. [verify on N100]

Footnotes

1. CLAP remote-controls extension (stable, clap.remote-controls/2): plugin-defined pages of 8 mappable controls. https://github.com/free-audio/clap/blob/main/include/clap/ext/remote-controls.h ↩