deepdrft/product-notes/phase-9-mix-visualizer-redesign.md

# Phase 9 — Wave 8.K: Mix Visualizer Redesign (Interview Question Set)

Status: **design pending interview**. Author: product-designer. Date: 2026-06-13.
**No implementation spec exists or should be written until the interview runs.**

Cross-references: `PLAN.md §9.8` (Wave 8 entry, 8.K), `product-notes/phase-9-wave-8-remediation.md §4`,
`product-notes/phase-9-release-medium-types.md §5.4` (the original `MixWaveformVisualizer` design).

---

## Purpose

Daniel wants the Mix Visualizer **completely redesigned** and has **explicitly asked to be interviewed**
before any design is committed. This document is the structured question set the-boss relays to Daniel
to run that interview. It is **not** a spec. When the interview produces answers, they get captured here
(or in a successor design note), and only then does 8.K become implementable.

---

## Current implementation (grounded, read 2026-06-13)

So the questions are anchored in what exists rather than asked blind:

- **Component:** `MixWaveformVisualizer.razor` + `.razor.cs` in `DeepDrftPublic.Client/Controls/`.
- **What it renders today:** a **static** full-viewport background. It fetches a stored loudness profile
  (`WaveformProfileDto`, base64 loudness bytes [0,255]) via `IReleaseDataService.GetMixWaveform(releaseId)`,
  and builds **one closed SVG silhouette path** — a vertically mirrored continuous wave around the
  horizontal midline, stretched across the full viewport via `preserveAspectRatio="none"`. It is a
  single still shape; it does not move.
- **Layout:** rendered as the full-page background behind the Mix detail content
  (`MixDetail.razor` places `<MixWaveformVisualizer>` behind a `.mix-detail-foreground` stacking layer).
- **Played-portion wash:** a `<rect>` clipped to the silhouette, width = `PlaybackPosition * width`,
  washes the played portion. `PlaybackPosition` is a normalized [0,1] input.
- **Seek seam (inert):** `OnSeek` callback + two-way `PlaybackPosition` binding exist but click-to-seek
  is **not wired** — the seam was added for a future wave.
- **Data resolution:** the profile is the **high-resolution** Mix waveform datum computed server-side
  (§9.2.B trigger) and stored in the vault; distinct from the player-bar low-res peek.
- **Explicit design boundary (from §5.4):** this component is deliberately **NOT** the player-bar
  peak-bar idiom (`SpectrumVisualizer` / `LevelMeterFab`). Those own the player bar; the Mix visualizer
  has its own visual language.

**Daniel's seed idea for the redesign:** NOT a static background image. Instead the waveform **scrolls
from the bottom of the screen to the top** in **high resolution**, with a **slider controlling scroll
speed / zoom level** — higher resolution moves faster. That is the entire brief so far; the interview
fills in the rest.

---

## Interview questions

Grouped by theme. Relay to Daniel; capture answers inline or in a successor note.

### A. Motion & scroll behaviour

1. The waveform scrolls **bottom-to-top**. Is it the *whole mix's* waveform scrolling past (like a
   scrolling score / piano-roll), or a *windowed* segment around the playback head? I.e. does the
   waveform represent the entire track laid out vertically and scroll through it, or a moving window?
2. Is scroll **coupled to playback** (the visualizer scrolls because the track is playing, position =
   playhead), or is it a **free ambient motion** independent of playback (scrolls even when paused /
   nothing is playing)? Or both modes?
3. If coupled to playback: does the **current playback position** sit at a fixed point on screen (e.g.
   always centre, or always at the top "now" line) with the waveform flowing past it? Where is "now"?
4. What happens at the **start and end** of the mix? Does it scroll in from empty / scroll out to empty,
   loop, or hold?
5. Direction is bottom-to-top — is that fixed, or is direction itself something to play with (some
   visualizers run top-down)? Confirm bottom-to-top is the intent.

### B. Zoom / resolution coupling (the slider)

6. The slider couples **scroll speed and zoom/resolution** ("higher res moves faster"). Unpack the
   coupling: does higher zoom mean (a) more waveform detail visible per unit height *and* faster scroll,
   or (b) you're "zoomed in" on a shorter time-span so the same playback rate covers more screen, hence
   faster apparent motion? These feel different — which is the mental model?
7. Is the slider a **single control** that ties speed and zoom together (one dimension), or do you want
   **independent** control of zoom and speed (two sliders / a 2D control)?
8. What's the **range**? At minimum zoom, roughly how much of the mix is visible on screen (the whole
   thing? a few minutes?); at maximum zoom, how fine (individual transients? bars/beats)?
9. Does the slider position **persist** across mixes / sessions, or reset each time? Is there a sensible
   **default** zoom the page opens at?
10. Should the high-resolution datum support the deepest zoom you want, or is there a resolution ceiling
    we should know about? (The stored datum has a fixed bucket count — extreme zoom may exceed its
    resolution. Worth knowing the target so the datum resolution can be set to match.)

### C. Colour & aesthetics

11. What's the **visual feel** you're after — is this meant to be hypnotic/ambient (a lava-lamp you can
    stare at), informational (read the structure of the mix), or both? What makes it "pleasing" to you?
12. **Colour treatment:** single colour, gradient, theme-aware (light/dark palette — "Charleston in the
    Day" / "Lowcountry Summer Nights")? Should it react to anything (frequency, intensity, time)?
13. Does the **played vs. unplayed** distinction matter in the scrolling model the way the wash does
    today? Or in a scroll-past model is "played" simply "already scrolled off the top"?
14. **Form of the wave:** keep the mirrored-silhouette filled shape, or something else — lines, bars,
    particles, a denser spectral look? You said high-resolution; what does high-res *look* like to you?
15. Does it stay a **full-page background** behind the detail content (as today), or become a more
    central/foreground element of the Mix detail page? Does the detail content (title, metadata, play
    control) still sit over it?

### D. Interaction model

16. Is the visualizer **interactive**? The current build has an inert click-to-seek seam. Do you want
    **click/scrub-to-seek** on the scrolling waveform — and if so, how does seeking interact with a
    moving target (click a point as it scrolls past? scrub a position?)?
17. The slider is one control. Any **other controls** on the visualizer surface — play/pause, a
    "follow playhead vs. free-scroll" toggle, anything?
18. On **touch / mobile**: does the scroll respond to touch gestures (drag to scrub, pinch to zoom), or
    is it display-only on mobile with the slider as the only control?
19. Should the visualizer be **reusable** beyond the Mix detail page (the §5.4 brief made it a named
    reusable component — e.g. a mix card preview, an embed)? Does the scrolling behaviour need to work
    at small sizes, or is it a full-page-only treatment?

### E. Performance & technical constraints

20. Smooth bottom-to-top scrolling at high resolution is a **continuous animation** — likely Canvas or
    WebGL rather than the current static SVG (SVG won't animate a high-res scroll smoothly). Are you
    open to that rendering-tech shift, or is there a reason to stay SVG?
21. What's the **target experience** — buttery 60fps on desktop, with a graceful degrade on weaker
    devices/mobile? Any device floor we should design to?
22. Does the scroll animation need to **keep running** while audio streams/decodes (the player is a
    chunked streaming pipeline), or only animate once enough is buffered? Should it react to buffering
    state at all?
23. Is there a **battery / ambient** concern — should it pause/slow when the tab is backgrounded or the
    mix is paused, to avoid a CPU-hot idle animation?

### F. Scope & sequencing

24. Is this a **replace-in-place** of the current static visualizer (same data, same page slot, new
    rendering), or does it pull in new data needs (e.g. higher-resolution datum, frequency/spectral data
    the stored loudness profile doesn't carry)?
25. Is the scrolling visualizer a **must-ship for Phase 9 completion**, or can Phase 9 close with the
    current static visualizer and the scroll redesign land as a fast-follow? (Affects whether 8.K blocks
    calling Phase 9 done.)
26. Are there **references** — other visualizers, apps, videos — that capture the feel you want? A
    concrete "like that, but…" anchors the design far better than abstract description.

---

## After the interview

Capture Daniel's answers (here or in a successor design note), then this track converts from
`[design pending interview]` to a real implementation spec — at which point the rendering-tech decision
(question 20), the data-resolution question (10, 24), and the interaction model (16–18) are the three
things most likely to drive the build's shape and should be settled first.