The problem
The waveform lanes only ever show the whole track. There is no way to look
closer at a bar, a transition, or the exact frame where a fill starts.
On a four minute song in a 900 px panel that is roughly a quarter of a second
per bar, so anything shorter than a beat is a single bar and anything shorter
than that is invisible. The beat grid editor, the loop region and the section
markers all ask the user to place something precisely on a timeline they cannot
see precisely.
What makes it harder than adding a zoom factor
The bars are the art, and they are easy to break. Each lane is an SVG whose
viewBox width is the bar count, drawn with preserveAspectRatio="none".
Widening that element without redrawing multiplies every bar's width by the zoom
factor. The result reads as a zoom at a glance and is really the same picture
with fatter strokes: no new information, and it stops looking like the app.
There are two render paths and they zoom differently. When the Web Audio
engine owns playback the lanes are the SVG overlay; on the streaming path they
are WaveSurfer canvases. Whatever drives the zoom has to reach both.
The source resolution is finite. peaks.json carries 1500 points per stem. A
zoom that asks for more bars than there are points behind them starts repeating
neighbours, which looks like detail and is not. That puts a real ceiling on how
far in it is honest to go.
Everything else on the timeline is positioned as a percentage. The ruler
ticks, the playhead, the grid lines and the loop region all share one coordinate
system with the lanes. They stretch with the canvas for free, which is what
makes them correct at any width -- and also means the ruler shows the same six
tick labels spread over five screen widths, getting less useful the further in
you go.
The loop region assumes the whole track is visible. It is defined by
dragging across the timeline and drawn as a percentage of it. Zoomed in, a drag
selects a region whose ends are off screen, and the overlay marks a span of a
timeline the user can only see a fifth of.
Constraints
- Zooming out past the fitted view shows nothing: the track is already entirely
on screen, so 1x is a floor rather than a default.
- The lane stack and the mixer column mirror each other's vertical scroll, so
whatever gesture drives the zoom has to leave a way to scroll lanes.
- Every user-facing string goes through the i18n layer, in all nine tables.
The problem
The waveform lanes only ever show the whole track. There is no way to look
closer at a bar, a transition, or the exact frame where a fill starts.
On a four minute song in a 900 px panel that is roughly a quarter of a second
per bar, so anything shorter than a beat is a single bar and anything shorter
than that is invisible. The beat grid editor, the loop region and the section
markers all ask the user to place something precisely on a timeline they cannot
see precisely.
What makes it harder than adding a zoom factor
The bars are the art, and they are easy to break. Each lane is an SVG whose
viewBox width is the bar count, drawn with
preserveAspectRatio="none".Widening that element without redrawing multiplies every bar's width by the zoom
factor. The result reads as a zoom at a glance and is really the same picture
with fatter strokes: no new information, and it stops looking like the app.
There are two render paths and they zoom differently. When the Web Audio
engine owns playback the lanes are the SVG overlay; on the streaming path they
are WaveSurfer canvases. Whatever drives the zoom has to reach both.
The source resolution is finite. peaks.json carries 1500 points per stem. A
zoom that asks for more bars than there are points behind them starts repeating
neighbours, which looks like detail and is not. That puts a real ceiling on how
far in it is honest to go.
Everything else on the timeline is positioned as a percentage. The ruler
ticks, the playhead, the grid lines and the loop region all share one coordinate
system with the lanes. They stretch with the canvas for free, which is what
makes them correct at any width -- and also means the ruler shows the same six
tick labels spread over five screen widths, getting less useful the further in
you go.
The loop region assumes the whole track is visible. It is defined by
dragging across the timeline and drawn as a percentage of it. Zoomed in, a drag
selects a region whose ends are off screen, and the overlay marks a span of a
timeline the user can only see a fifth of.
Constraints
on screen, so 1x is a floor rather than a default.
whatever gesture drives the zoom has to leave a way to scroll lanes.