# 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 `` behind a `.mix-detail-foreground` stacking layer). - **Played-portion wash:** a `` 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.