docs: spec Phase 9 Wave 8 remediation + Mix Visualizer interview set

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

@@ -0,0 +1,142 @@
+# 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.