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.