reasampler/docs/product/visual-design-language.md

# Visual design language — ReaSampler + ReaSampler 9000 (Phase L)

System-wide look-and-feel framing. This is the **why** and the visual spec for the
whole-system look-and-feel effort, now carried as its own **Phase L** (Look-and-feel):
the shared LICE drawing kit (**L1**), the extension's docked bank-panel layout redesign
(**L2**), and the ReaSampler 9000 VST editor + embed-strip restyle (**L3**). It was
written after Daniel DAW-tested the S1–S6 instrument:

> "this shit looks like temple os. it's 2026, we need something more modern and sleek.
> speed is the selling point. […] If we are going to enhance look and feel, we need to
> think big and full. Scope it out for the whole system. […] the VST is dogshit. Does
> Cockos have a toolkit for this type of visual design?"

**Status:** framed by product-designer (2026-07-26); the DS-1/DS-2/DS-3 forks are
**SETTLED (Daniel, 2026-07-26)** — recorded in §6 with the reasoning preserved. The
build points it feeds live in **PLAN.md §Phase L** (**L1** the shared LICE drawing kit,
**L2** the dock-panel layout redesign, **L3** the VST editor + embed-strip restyle) and
**CONTEXT.md §Phase L** (the design-system spec). Toolkit facts below are **verified
against the vendored `vendor/WDL` tree**, not lore.

> **Phase-boundary note (2026-07-26).** This look-and-feel effort was originally drafted
> as Phase S points **S0-DS** (the shared kit) and **S14** (the panel refresh). It was
> **lifted out of Phase S into its own Phase L** so a parallel team can take it up
> without Phase S context and so Phase S feature work (S7–S13) proceeds ungated. The old
> `S0-DS` content is now **L1**; the old `S14` content is now **L2** (expanded from a
> light re-skin into a thorough layout redesign — see DS-3 below); the VST editor +
> embed-strip restyle, which S10–S13 originally folded in, is now the explicit **L3**
> point, **gated on Phase S landing on dev**. Phase S's S10–S13 build their interaction
> UX with the current drawing and **adopt the L1 kit when it lands** — they are not
> gated on Phase L.

---

## 0. TL;DR

- **Cockos ships exactly the toolkit Daniel asked about**, and it's already vendored.
  Two layers: **LICE** (the immediate-mode 2D rasterizer — gradients, anti-aliased
  lines/circles/round-rects/beziers, alpha blending, and a real font engine with
  shadow/outline/glow effects) and **WDL VirtualWnd / vwnd** (a retained-mode LICE-drawn
  *widget* layer — buttons, sliders, knobs, listboxes, skins — the thing REAPER and SWS
  themselves are built on). **The current VST editor uses almost none of it** — it draws
  flat `LICE_FillRect` blocks and pipes text through raw GDI `DrawTextA`. *That* is the
  "temple os" look: no gradients, no anti-aliasing, no rounded corners, no hover, aliased
  system text. The ceiling is not the problem; we're drawing at the floor.
- **DS-1 SETTLED (2026-07-26): LICE, and anything useful in WDL is free game.** "Don't
  reinvent the wheel" — if vwnd (or any WDL machinery: skin/image helpers, draw idioms)
  offers a usable piece, use it; otherwise build on LICE. **No external frameworks**
  (not JUCE, not iPlug2, not VSTGUI). LICE can deliver a 2026-modern dark synth UI —
  REAPER's own themed UI and SWS prove the ceiling. This is fully consistent with the
  settled **D-A** decision (bare SDK + LICE, no framework); the fork is recorded in §6.
- **The real work is L1 — a shared drawing kit** — one small LICE-based
  component/palette/type layer that the VST editor, the embed strip, and the bank panel
  all draw through. It is the one source of drawing for the whole system.
- **DS-2 SETTLED (2026-07-26): Direction B ("Neon Console") + Direction C's spectral
  keyboard strip** as the signature surface. Three visual directions are in §4; B+spectral
  is the settled target. "Speed is the selling point" is a **design constraint**, not a
  tagline: the UI must *feel* instant (§3.5).
- **DS-3 SETTLED (2026-07-26): the dock-panel work is a real, thorough layout design, not
  a light reskin.** L2 lays out the *full button inventory* (including M11's additions)
  intuitively, uncluttered, and useful — §5.2.

---

## 1. The toolkit question, answered from the vendored source

Daniel: *"Does Cockos have a toolkit for this type of visual design?"* Yes — two layers,
both already in `vendor/WDL`. Verified by reading the headers, not from memory.

### 1.1 LICE — the rasterizer (this is the load-bearing answer)

`vendor/WDL/WDL/lice/` is Cockos's own 2D graphics library — the same one REAPER's UI,
the theme engine, and SWS draw with. The current `bank_panel` and VST editor already link
it. What it actually offers, beyond the flat `LICE_FillRect` the editor currently limits
itself to (all verified in `lice/lice.h` / `lice/lice_text.h`):

| Capability | Function (verified) | We use it today? |
|---|---|---|
| **Gradient fills** | `LICE_GradRect` (per-axis R/G/B/A ramps) | **No** — this alone kills the flat look |
| **Anti-aliased lines** | `LICE_Line`/`LICE_FLine`/`LICE_ThickFLine` (`aa=true` default) | No |
| **Rounded rectangles** | `LICE_RoundRect` (corner radius, AA) | No |
| **AA circles / knobs** | `LICE_Circle`/`LICE_FillCircle` | No |
| **Bezier curves** | `LICE_DrawCBezier` (AA envelope/curve draw) | No |
| **Triangles / polygons** | `LICE_FillTriangle`/`FillConvexPolygon`/`FillTrapezoid` | No |
| **Alpha compositing** | every primitive takes `alpha` + blend `mode` | Barely (opaque only) |
| **Real font engine** | `LICE_CachedFont` / `LICE_IFont`: `SetFromHFont`, AA glyph cache, `SetTextColor`, `DrawText` | **No — we use raw GDI `DrawTextA`** |
| **Text effects** | shadow / outline / glow / blur (`LICE_FONT_FLAG_FX_SHADOW`/`_OUTLINE`/`_BLUR`) | No |

**The single biggest visual lever is text.** The editor's `drawText` does
`GetDC` → `SetTextColor` → `DrawTextA` — native, un-anti-aliased-in-the-bitmap GDI text
that reads as "1998." Switching to a `LICE_CachedFont` (created once from a chosen
`HFONT`, cached, AA glyphs, optional soft shadow) is the difference between "temple os"
and "modern synth." Small, mechanical change, outsized payoff, and it belongs in L1 (§5)
so every surface gets it at once. `bank_panel` already routes some text through GDI too;
the kit fixes both.

**Conclusion:** LICE is a genuine, sufficient 2D toolkit for a modern dark synth UI. The
gap between the current editor and a sleek one is entirely in *which LICE calls we make*,
not in LICE's ceiling. **No new dependency is required to get the look Daniel wants.**

### 1.2 WDL VirtualWnd (vwnd) — the retained-mode widget layer, and DS-1's "free game" rule

`vendor/WDL/WDL/wingui/virtwnd*.{h,cpp}` is the layer above LICE: `WDL_VWnd` (a virtual
window / control that draws itself into a shared LICE bitmap), with concrete controls —
`virtwnd-iconbutton.cpp` (buttons), `virtwnd-slider.cpp` (sliders +
`vwnd_slider_drawknobstack` knob rendering), `virtwnd-listbox.cpp` (scrolling lists),
`virtwnd-skin.h` (image-based skins), plus `WDL_STYLE_*` hooks for background gradients
and slider/knob bitmaps (`virtwnd-controls.h`). **This is the toolkit REAPER and SWS
themselves use for custom UI.**

**DS-1's settled rule: WDL is free game — don't reinvent the wheel.** Where a WDL piece
(a skin/image helper, a draw idiom, a specific control's rendering) is genuinely usable
and cheaper than re-deriving it, **use it**; otherwise build on LICE directly. The one
standing caution — not a prohibition — is the **retained-mode object model**: vwnd's
controls own their hit-test/drag/value internally, whereas the house discipline keeps
layout/hit-test in **pure geometry modules** (`mode_switch`, `embed_strip`,
`editor_geometry`, the planned `keyboard_strip`) so hit-test math stays CTest-covered
outside the DAW. So the default is to **borrow vwnd's drawing craft** (read
`virtwnd-slider.cpp` / `vwnd_slider_drawknobstack` as the reference for a good LICE
slider/knob and reproduce the look procedurally over pure geometry we own) and to reach
for a vwnd *object* only where it carries no bespoke-geometry requirement and re-deriving
it is genuinely wasteful. The plain **scrolling listbox** (`virtwnd-listbox.cpp`) for a
long sample list is the archetypal "just use it" case — no bespoke drawing, tedious to
re-derive; adopt it if it fits at build time. The **keyboard strip and waveform** are
bespoke surfaces vwnd has no widget for — custom-drawn regardless. The rule is a
build-time judgment call per piece, made under one principle: **reuse what WDL gives us,
keep hit-test geometry testable.**

### 1.3 The frameworks we are NOT taking (and why — DS-1 settled: no external frameworks)

- **IPlug (WDL's own `IPlug/`)** — the VST2-era plugin framework in WDL. **Dated and
  irrelevant.** VST2 is deprecated; it predates VST3; it's not a UI toolkit anyway. Ignore.
- **iPlug2** (the modern community fork — NanoVG/Skia GPU renderers, web-UI option) — a
  genuinely capable modern framework, but it is a **whole new plugin-framework dependency**
  that would **replace** the bare-SDK + LICE architecture **D-A** settled on 2026-07-26. It
  brings its own graphics stack (NanoVG/Skia), its own build integration, and its own
  editor/parameter model — none of which we need, because LICE already clears the bar.
  **Rejected** (DS-1 settled: no external frameworks).
- **VSTGUI** (bundled with the Steinberg SDK) — the noted D-A fallback rung *if the
  IPlugView↔LICE bridge had proven gnarly*. On the phase-s worktree it didn't — S1 landed
  the bridge, the editor draws in LICE today. VSTGUI is moot; we're past the point it hedged.

**Net:** the toolkit question resolves cleanly. Use **LICE** (already in hand, already the
draw surface) as the toolkit, **reuse WDL/vwnd pieces where useful** (DS-1's "don't
reinvent the wheel"), and **take no external framework.** Fully consistent with D-A.

---

## 2. Palette — dark, modern, punchy

Daniel's standing taste: **visual punch over conservative contrast** — push vibrancy to
the WCAG floor for each element class, not to the past-safe gray. The current palette
(shared between `bank_panel.cpp` and the VST editor) is a muted forest-green-on-charcoal:
background `RGB(28,28,30)`, waveform/accent `RGB(120,200,160)`, cell `RGB(44,44,48)`. It's
*coherent* but *timid* — one desaturated accent, flat fills, hairline borders.

### 2.1 Structural roles (direction-independent)

A modern dark UI is built from **elevation layers**, not borders. Define the palette by
role, then let the direction set the accent:

| Role | Purpose | Current | Direction |
|---|---|---|---|
| `bg/base` | window canvas | `28,28,30` | deepen slightly + a **subtle top-down `LICE_GradRect`** (base look, not flat) |
| `bg/panel` | a raised region (list, waveform pane) | — (implicit) | one step lighter than base; elevation reads without a border |
| `bg/cell` | a control/row surface | `44,44,48` | as now, but with a 1px inner top highlight (the vwnd trick) |
| `line/hairline` | separators | `60,60,66` | keep, use sparingly — elevation should carry most separation |
| `text/primary` | labels, values | `210,230,220` | near-white, **must clear WCAG AA (4.5:1) on `bg/panel`** |
| `text/dim` | secondary / units | — | a dimmer step, still **AA-large (3:1) minimum** — the WCAG floor, not below it |
| `accent` | selection, active, focus | `120,200,160` | **Direction B: one vivid hue** (§4) — this is where the punch lives |
| `accent/hot` | hover / live / drag feedback | — (absent) | a brighter accent tint; **today there is no hover color at all** |
| `warn` | clip / destructive (prune, delete) | — | a red/amber reserved *only* for byte-deleting or clip states |

**WCAG-floor discipline (the "punch" rule, concretely):** for each text-on-surface pair,
pick the *most* saturated/vibrant accent that still clears its contrast floor — AA 4.5:1
for body text, 3:1 for large text and for UI-state indicators (selection borders, active
fills). Do not retreat to safe grays "to be sure." The floor is the target, approached
from the vibrant side.

### 2.2 Motion of color, not just color

The flat look isn't only the hue — it's that every fill is a **single opaque rectangle**.
A 2026 dark UI reads as dimensional because surfaces have a **micro-gradient** (a few
percent lighter at the top, `LICE_GradRect`) and controls have a **1px top inner-highlight
+ 1px bottom inner-shadow**. This is the single cheapest "modern" upgrade after AA text,
and it's exactly what `virtwnd`'s button/slider drawing does. Bake it into the kit's
`fillSurface()` primitive so every button, row, and cell gets it for free.

---

## 3. Typography, spacing, interaction, motion

### 3.1 Typography within LICE's reality

- **Use `LICE_CachedFont`, retire raw GDI `DrawTextA`.** Create a small set of cached
  fonts once (below), owned by the kit, reused across VST + embed + panel. AA glyphs in
  the bitmap are the "temple os → modern" switch.
- **Two or three weights/sizes, no more.** A tool UI wants a **type scale**, not
  typographic variety: `title` (~15px semibold), `label` (~12px regular), `value`/`mono`
  (~12px, tabular for note numbers / ms / dB so digits don't jitter during a drag),
  `micro` (~10px, dim, for units/counts). Four cached fonts total.
- **Font choice:** a clean UI sans is available on every Windows target (Segoe UI is the
  safe system default; the kit takes an `HFONT`, so the exact face is a one-line change).
  For the numeric `value` role, a tabular/mono face (Consolas is universally present)
  keeps dragged numbers from reflowing. Windows-only (D5) means no cross-platform
  font-fallback worry.
- **Soft shadow on title/accent text only** (`LICE_FONT_FLAG_FX_SHADOW`) — subtle depth,
  used sparingly; body text stays crisp and flat for legibility.

### 3.2 Spacing & grid

- **An 8px base unit** (4px for tight internal padding). Row heights, gaps, and pane
  insets are multiples of it — this is what makes a UI read as "designed" not "placed."
- **Generous row height** for list/zone rows (~28–32px). In the editor, S10 deletes the
  seven mini-buttons per row so rows can breathe.
- **Consistent 8px pane inset** everywhere (panel edges, between panes). The current
  editor pins controls flush to edges — a big part of the cheap feel.

### 3.3 Interaction states (the editor currently has NONE)

A control looks identical whether the mouse is over it, on it, or nowhere near. **This is
half of why it feels dead.** Define a state model every kit component honors:

| State | Visual | Cost |
|---|---|---|
| **rest** | `bg/cell` + inner highlight | — |
| **hover** | lighten fill toward `accent/hot`, ~8–12% | requires `WM_MOUSEMOVE` tracking (§3.5) |
| **active/selected** | `accent` fill + `accent` border | already partly present |
| **pressed** | darken + 1px inset (the surface "pushes in") | on `WM_LBUTTONDOWN` |
| **dragging** | live element follows cursor; ghost/marker at target; rest dims slightly | S10 drag machine |
| **focus (keyboard)** | 1px `text/primary` ring (distinct from selection) | already present in panel (`kColFocusBorder`) |
| **disabled** | desaturate + 40% alpha | rare (stale zone, no bank) |

Hover is the highest-value addition — it's what makes a UI feel *alive* and responsive,
and the visible proof of "speed is the selling point" (§3.5). It requires
`WM_MOUSEMOVE` (and `TrackMouseEvent` for `WM_MOUSELEAVE`). The panel's `wndProc` already
runs a timer; adding hover tracking is cheap. In the editor, the S10 drag-state machine
already introduces the move tracking, so hover rides in on that work at near-zero cost.

### 3.4 Component patterns (reused across VST + embed + panel)

The kit defines a **small, shared vocabulary** of drawn components, each: (a) drawn by a
kit function taking a `Rect` + state, (b) hit-tested by a **pure geometry** helper (the
house discipline). The set:

- **Button** — rounded (`LICE_RoundRect`), gradient fill, inner highlight, hover/pressed
  states, centered `LICE_CachedFont` label. Replaces the flat `LICE_FillRect` +
  `DrawRect` + GDI-text buttons in both artifacts (the whole M11 action-button
  inventory, panel toggles, prune button, Add Zone, etc.).
- **List row** — selectable, hover, focus, optional leading thumbnail (the panel's
  waveform cell is a specialization). Shared by the sample list (VST + panel) and zone
  list.
- **Slider / knob** — for ADSR (S12) and any level control; drawn in the
  `virtwnd-slider` idiom (track + filled portion + handle with highlight), hit-test pure.
- **Marker / handle** — the draggable grip primitive: keyboard-strip zone edges (S10),
  waveform loop markers (S11). A consistent grip look (a bright vertical bar + a small
  triangular tab) so "this is draggable" reads instantly.
- **Segmented switch** — the panel already has this (`mode_switch`); restyle it through
  the kit (gradient segments, lit-active, hover).
- **Tab (named-banks strip)** — a specialization of the segmented/button idiom with the
  overflow/scroll affordance already specced in Phase B; drawn through the kit.
- **Waveform** — peaks envelope (`peaks` module) drawn as a filled AA shape
  (`LICE_FillTriangle`/trapezoids or a bezier top), midline, over `bg/panel`. Shared
  between the panel thumbnail and the S11 editor waveform.
- **Keyboard strip** — the bespoke S10 surface: white/black key lanes, zone bars as
  translucent colored overlays, root markers. No prior art in the kit; it *defines* new
  kit primitives (key-lane fill, zone overlay). **Direction C's spectral treatment
  (§4, DS-2 settled) lives here** — the hue-mapped keyboard is the signature surface.

### 3.5 Motion policy — "speed is the selling point," read as a constraint

Daniel named speed as *the* selling point. The design reading: **the UI must feel
instant, and no decoration may cost that.** Concretely —

- **Sub-frame response.** Hover/press/drag feedback repaints immediately on the input
  message (no timer latency). This is why hover tracking is a *feature*, not overhead —
  instant visual acknowledgment is the *perception* of speed.
- **Zero-jank drawing.** Keep the existing **double-buffer** discipline (draw to a
  `LICE_SysBitmap`, single `BitBlt`) the editor and panel already use. Every kit
  component draws into the offscreen bitmap; nothing draws direct-to-DC.
- **Repaint only what changed where cheap.** Full-panel repaint is fine at these sizes,
  but during a drag, invalidate the affected region (`InvalidateRect` with a rect, not
  `nullptr`). Build-time residual, flagged not mandated.
- **NO decorative animation.** No easing tweens, no fades, no animated meters beyond a
  direct level follow. Animation that costs a frame of latency **violates** the speed
  promise. The one permitted case: a level/meter readout that follows the audio directly
  (already how the embed strip's level band works). Motion = immediate feedback, never
  ornament. **Direction C's glow/bloom is a drawn *state*, never a pulse** — it must stay
  static.
- **The "fast" feeling is mostly typography + hover + no-jank**, not motion. A crisp AA
  label that lights on hover and commits a drag with zero flicker *reads* faster than any
  animation.

---

## 4. Three visual directions (DS-2 SETTLED: B + C's spectral keyboard strip)

Each is a complete palette + treatment, not a shade of the same thing. All three are
LICE-drawable today (no new dependency); all three honor the WCAG-floor "punch" rule.
Ordered safe → bold. **Daniel settled (2026-07-26) on Direction B as the target, with
Direction C's spectral keyboard strip as the signature surface.**

### Direction A — "Studio Rack" (evolutionary; not selected)

The current forest-green-on-charcoal, but *executed properly*: gradient surfaces, AA
text, rounded controls, a hover state, inner highlights. Same hue family — accent stays
green (brightened to `~140,220,170`), background gains a subtle vertical gradient,
controls get the vwnd inner-highlight/shadow treatment.

- **Feel:** a well-made piece of pro audio hardware. Restrained, "REAPER-native."
- **Why not selected:** it's the *conservative* answer — fixes "temple os" but doesn't
  make anyone say "sleek." Retained as the fallback if B/C ever feel too loud for a
  pro-audio context, but Daniel's taste points away from it.

### Direction B — "Neon Console" (contemporary synth; SETTLED default)

A modern soft-synth / plugin look: near-black background (`~18,18,22`) with a **single
vivid accent** (electric cyan `~60,200,235` leads; hot magenta `~235,70,170` is the
bolder sub-option), used with intent for the *live/active/selected* layer only. Everything
else is a calm neutral gray scale; the accent does all the punch. Waveforms and the
keyboard strip's active zone glow in the accent; inactive elements are quiet gray. This is
the "Serum / Vital / modern Arturia" idiom — vivid-accent-on-near-black.

- **Feel:** a 2026 instrument. Sleek, focused, the accent guides the eye to what's live.
- **Accent:** one vivid hue (cyan leads). Clears WCAG-large comfortably at full saturation
  on near-black — "push to the floor from the vibrant side." A second dimmer tint for
  hover. **This is the settled target** — the strong-but-safe center; the single-accent
  discipline is easy to keep coherent across VST + embed + panel.
- **Watch:** a single vivid accent can feel "gamer" if over-applied — discipline required
  (accent = live only, never chrome). One hue is a commitment; changing it later is a
  palette sweep (cheap in the shared kit — one constants block — but a sweep).

### Direction C — "Spectral" (bold; SETTLED for the keyboard strip)

Lean *all the way* into vibrancy and depth. Near-black base, but the accent is a
**two-color gradient** — zones and the waveform aren't a flat accent, they're a
**hue-mapped gradient** (e.g. low notes cool-blue → high notes hot-magenta across the
keyboard strip; the waveform filled with a vertical accent gradient). Selection glows; the
active zone has a soft outer bloom (`LICE_GradRect` halo). Multi-zone keymaps become
genuinely *beautiful* — each zone a band of the spectrum — which is exactly the
"multi-zone-in-one-instance" capability that RS5K structurally lacks (the sharpest
"better than RS5K" claim, made *visual*).

- **Feel:** premium, almost visualizer-grade. The keyboard strip becomes a signature — a
  spectrum you play across.
- **Settled scope:** **C's spectral treatment lands on the keyboard strip** (the signature
  surface), over Direction B's Neon-Console chrome everywhere else. This is the
  "modern-sleek center with one bold, identity-defining surface" Daniel chose — dial the
  spectrum up (full C across more surfaces) or down (pure B) after seeing it on the DAW.
- **Watch:** gradients/bloom are easy to overdo into "toy"; the glow must stay a static
  drawn state, never a pulse (§3.5); risks reading as *flashy* over *fast* if the speed
  discipline slips.

**Settled recommendation, now spec:** build the **kit palette abstractly** (roles, not
hardcoded colors — §2.1) so the direction is *one file of constants*; **default to
Direction B (Neon Console)** with **Direction C's spectral keyboard strip** as the
signature surface. Because the palette is abstract, a later re-pick is one file.

---

## 5. The build shape (feeds PLAN.md / CONTEXT.md §Phase L)

Three points and their sequencing.

### 5.1 `L1` — shared LICE drawing kit (the foundation)

A small shared module — the palette + type + component-draw layer that the VST editor,
the embed strip, and the bank panel all draw through. Honoring the house pure/shell split:

- **Pure layer (CTest-covered):** the *geometry* of components — a `theme`/palette module
  (role → color, direction-selectable via one constants block; pure, trivially testable
  that contrast pairs clear their floor with the B+spectral constants) and per-component
  **layout/hit-test** helpers where they don't already exist (button rect, slider
  track/handle geometry, list-row rect + hover hit-test). These mirror
  `mode_switch`/`embed_strip`/`editor_geometry` — no LICE, no host types, unit-tested.
- **Shell layer (DAW-verified):** the **draw kit** — LICE functions that render each
  component (`drawButton`, `drawSlider`, `drawListRow`, `drawWaveform`, `fillSurface` with
  the micro-gradient + inner highlight, `text()` via a shared `LICE_CachedFont` set). Owns
  the cached-font lifecycle. **WDL/vwnd reuse is assessed here, at build time, per DS-1** —
  reuse a vwnd piece where it's genuinely cheaper (the scroll listbox is the archetype),
  else draw on LICE. This is the layer that *replaces* the flat `LICE_FillRect` +
  `DrawTextA` calls in every surface.
- **Cross-artifact reuse (load-bearing):** the kit is the **one source** all surfaces
  draw through — the same instinct as the one-source-multiple-views rule. A button looks
  identical in the panel, the embed strip, and the VST because it's the same `drawButton`.
  This is what makes "scope it for the whole system" real rather than divergent restyles.
- **Coordination with Phase S:** L1 is not S10's dependency — S10–S13 build their
  interaction UX with the *current* drawing and **adopt the kit when L1 lands** (whichever
  order happens). The kit is the one source of drawing; when both exist, all surfaces
  consume it.

### 5.2 `L2` — dock-panel layout redesign (extension-side; DS-3 SETTLED: thorough, not a re-skin)

**DS-3 settled (2026-07-26): this is a real, thorough layout design, not a light reskin.**
The panel already has good bones (thumbnails, selection, focus ring, a LICE grid, the
multi-bank vertical split, the Design View mode switch). But **M11 (about to merge to
dev)** adds a substantial button inventory — the panel must lay out the *full* inventory
intuitively, uncluttered, and useful. L2 designs that layout, then applies the L1 kit to
draw it.

**The full button/affordance inventory L2 must place (dev, M11-aware):**

*Existing (landed / specced):*
- Bank **grid** — thumbnails, multi-select, keyboard nav, audition, focus ring.
- Design View **segmented mode switch** (`[ Arrange | Design ]`) + per-mode membership count.
- Multi-bank: **named-banks tab strip** (LICE-drawn, overflow/scroll), **active-bank
  indicator**, **pool/banks full-height toggles**, create/rename/delete/activate-bank
  affordances, per-selection **move / copy / remove** sample menu.
- **Prune** button (R-E) — the byte-deleting action, `warn`-colored.

*M11 adds (dev PLAN.md M11 — merging now):*
- **Action trigger buttons** — clickable buttons that fire the capture + provenance
  action family directly (capture item / capture track scopes, re-capture from source,
  resample-and-mute-source, batch capture, conform-on-insert, insert-at-cursor, drag-out,
  null-test verify). A real cluster of buttons.
- **Keybinding help labels** — each capture/provenance action surfaces its current key
  binding (e.g. "Capture Item → F5") or an "unbound" marker.

**L2 design mandate (the thorough part):**
- **Group by function, not by phase.** The user thinks in *tasks* — capture, organize,
  reclaim, view — not in M/B/R/D phases. Cluster the capture-action buttons together
  (with their keybinding labels), the bank-organization affordances together (tabs +
  move/copy/remove + create/rename/delete), the view/mode switch in the header, and the
  destructive prune apart and `warn`-marked. First-principles: what does a capture-heavy
  workflow reach for most, and how few clicks/pixels away is it?
- **A place for every button that doesn't crowd the grid.** The grid is the centerpiece;
  the button inventory must not squeeze it. Consider a **compact action bar/toolbar** for
  the frequent capture actions (icon+label buttons drawn through the kit, keybinding as a
  `micro` sub-label), an **overflow/menu** for the rare ones, and reserved header space
  for view/mode. The keybinding labels are `micro`/`text-dim` so they inform without
  shouting.
- **Density is a design decision, not an accident.** Use the 8px grid (§3.2), elevation
  layers (§2.1) to separate the action bar from the grid from the bank strip without a
  forest of hairlines, and the kit's `warn` role to make prune (and any destructive verb)
  unmistakable. Hover on every interactive element (§3.3).
- **Then apply the L1 kit** to draw it all: cached-font text (retire the panel's GDI
  text), kit `drawButton`/segment/tab draws, palette roles, micro-gradient surfaces.
- **Hit-test geometry stays pure.** The layout redesign may add new pure geometry modules
  (an action-bar layout module, mirror of `mode_switch`/`bank_grid`) but keeps all
  hit-test math in the pure, CTest-covered layer. `bank_grid`/`tab_strip`/`mode_switch`
  stay the source of truth for what they own; new layout gets its own pure module.

**Sequence L2 AFTER M11 merges to dev** — L2 must inventory M11's *actual* landed buttons,
not a forecast of them. If L2 starts before M11 lands, it designs against a moving target.

### 5.3 `L3` — VST editor + embed-strip restyle (GATED on Phase S landing on dev)

The ReaSampler 9000 VST editor (`IPlugView` LICE surface) and the S6 embed strip get the
full kit treatment: cached-font text, kit component draws, the B+spectral palette, the
spectral keyboard strip as the signature surface, hover/pressed/drag states everywhere.

**L3 is explicitly GATED: these surfaces do not exist on dev yet.** The VST editor, the
embed strip, and the keyboard strip live in Phase S, which has landed on the phase-s
worktree but **not on dev**. L3 cannot be built on dev until Phase S (at least the editor
+ embed surfaces, S1/S6/S10) lands on dev. **The Phase L team must not chase these files
on dev** — the gate is stated so they don't. Until Phase S merges to dev, L3 is a planned,
blocked point; L1 and L2 are the live Phase L work.

**Coordination contract (stated once, load-bearing):** Phase S's S10–S13 build their
interaction UX with the *current* drawing and **adopt the L1 kit when it is available —
they are not gated on Phase L.** Whichever lands first (L1 kit or S10–S13 UX), the kit is
the **one source of drawing**; when both exist, the Phase S surfaces draw through it, and
L3 is the point that completes that adoption + applies the settled B+spectral look. If
S10–S13 land on dev before L1, they draw in the current language and L3 restyles them; if
L1 lands first, S10–S13 are born in the kit. Either way there is one kit, one look.

### 5.4 Sequencing summary

```
L1 (shared kit) ──► L2 (dock-panel layout redesign, extension-side; AFTER M11 merges)
        └─────────► L3 (VST editor + embed-strip restyle; GATED on Phase S landing on dev)

Phase S (separate team, ungated): S7…S13 build with current drawing, adopt L1 kit when it lands.
```

L1 is the foundation both L2 and L3 consume. L2 is extension-side and lands after M11. L3
is gated on Phase S reaching dev. Phase S feature work proceeds in parallel, ungated.

---

## 6. Forks — all SETTLED (Daniel, 2026-07-26)

**Fork DS-1 — the toolkit. SETTLED: LICE + WDL free game, no external frameworks.**

- **Settled:** draw the modern look with **LICE** directly (gradients, AA, rounded, cached
  fonts). **Anything useful in WDL/vwnd is free game** — "don't reinvent the wheel": reuse
  a vwnd piece (skin/image helper, draw idiom, a specific control like the scroll listbox)
  where it's genuinely usable and cheaper than re-deriving; otherwise build on LICE. The
  one standing caution (not a ban): keep hit-test **geometry** in pure CTest-covered
  modules rather than importing vwnd's retained-mode object model wholesale, so the
  pure/shell split and its test coverage hold.
- **Rejected:** any **external framework** — iPlug2, JUCE, VSTGUI. They re-open settled
  D-A to solve a look problem that is *not* a toolkit-ceiling problem (REAPER's own themed
  UI is LICE). WDL's own VST2-era `IPlug` is dated and irrelevant.
- **Reasoning preserved:** LICE is a sufficient modern-dark-UI toolkit; the current
  "temple os" look is drawing at LICE's floor, not hitting its ceiling. No new dependency,
  fully consistent with D-A.

**Fork DS-2 — visual direction. SETTLED: Direction B (Neon Console) + Direction C's
spectral keyboard strip.**

- **Settled:** **B** (near-black + one vivid accent, modern soft-synth idiom) as the
  system-wide target, with **C's spectral, hue-mapped keyboard strip** as the signature
  surface — the multi-zone-in-one-instance advantage made visual.
- **Not selected:** **A Studio Rack** (evolutionary green — retained only as a fallback if
  B/C read too loud for pro-audio).
- **Reasoning preserved:** modern-sleek center + one bold identity surface; Daniel reacts
  better to bold than to conservative. The kit palette is abstract (roles, one constants
  block), so this is **reversible for ~one file** — a starting direction, not a permanent
  lock.

**Fork DS-3 — panel refresh scope. SETTLED: thorough layout redesign (not a light
re-skin).**

- **Settled:** L2 is a **real, thorough layout design** that lays out the full button
  inventory (including M11's action buttons + keybinding labels) intuitively, uncluttered,
  and useful — then applies the L1 kit to draw it. Sequenced **after M11 merges** so it
  designs against the actual button set.
- **Superseded:** the earlier "(a) light — apply the kit, keep the structure" lean. M11's
  button additions make a *layout* pass necessary, not just a skin pass — a forest of new
  buttons crammed into the current structure would be exactly the clutter the redesign
  exists to prevent.
- **Reasoning preserved:** the panel's grid/vertical-split bones are sound and stay; the
  *layout of the button inventory around them* is the design work. Structural rework
  destabilizing landed Phase-B panel work is still avoided — L2 groups and places, it does
  not tear down the vertical-split / grid / tab structure.

---

## 7. What this does NOT change (guardrails)

- **D-A stays settled** — bare Steinberg SDK + LICE, no framework. This doc *reinforces*
  it (LICE is sufficient), it does not re-open it. (D-A lives on the phase-s worktree; on
  dev it is the settled Phase S build-shape decision.)
- **The pure/shell split holds** — all layout/hit-test stays in pure, CTest-covered
  geometry modules; the kit's *draw* half is shell, its *geometry* half is pure. No
  hit-test math moves into untestable code, even where a WDL piece is reused (DS-1).
- **RT discipline untouched** — the kit is draw-thread only; nothing here touches
  `process` or the off-thread reload handoff (Phase S concern).
- **Read-only-over-bank untouched** — this is look-and-feel; no data-ownership change.
- **The instrument keeps the same VST3 class UID / component-state contract** — a visual
  refresh is not a compat event (Phase S concern; noted for when L3 runs).
- **Windows-only (D5)** — the font/GDI/HFONT choices assume Windows; no cross-platform
  font fallback concern.
- **Phase S is not gated on Phase L** — S7–S13 proceed in parallel; they adopt the kit
  when it lands. Phase L (L1/L2) is the live work on dev; L3 waits for Phase S to reach dev.