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

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?
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?
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"?
What happens at the start and end of the mix? Does it scroll in from empty / scroll out to empty, loop, or hold?
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)

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?
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)?
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)?
Does the slider position persist across mixes / sessions, or reset each time? Is there a sensible default zoom the page opens at?
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

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?
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)?
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"?
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?
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

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?)?
The slider is one control. Any other controls on the visualizer surface — play/pause, a "follow playhead vs. free-scroll" toggle, anything?
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?
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

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?
What's the target experience — buttery 60fps on desktop, with a graceful degrade on weaker devices/mobile? Any device floor we should design to?
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?
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

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)?
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.)
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.

9.0 KiB Raw Blame History Unescape Escape