Tatsh / smlab / 32611079857

100%

push

github

warp: measure tempo drift, and let a chart carry more than one tempo

A chart is written against one grid, so a song that speeds up or slows down
cannot be charted correctly by any single tempo. What failed when this was last
attempted was the guessing, not the representation: TimingData has always been
segment-based and the writers have always emitted multi-segment BPMS, so the
only thing missing was a way to say where the tempo moves.

smlab drift says where. The beat phase is tracked against a fixed reference and
where the music runs faster or slower the tracked phase slides; the slope is the
tempo difference and the sign says which way. Phase per window is the argument
of the envelope's Fourier coefficient at the beat frequency rather than the peak
of a fold, because a fold's peak jumps to the off-beat whenever that peak is
momentarily the taller of the two and reads as a spurious half-period step. The
coefficient is biased late, an onset envelope being an impulse train with a slow
decay, but a constant bias does not survive differentiation and the measurement
is entirely in the slope.

--warp SECONDS:BPM places a marker, and may be given more than once. It lands on
the exact beat that moment falls on rather than the nearest whole one: rounding
would move the change by up to half a beat, which is the same tidying that made
a tempo of 128.199 come out as 128.000 and cost seven tenths of a beat across a
song.

Two places assumed a single tempo and now read the grid. Deciding how many notes
a chart holds measured the song by multiplying one tempo out, and the jack limit
took its spacing from that same tempo; the length now comes from the grid and
the spacing from the fastest stretch, which is where a slot is shortest and so
where a floor has to be set. Decoding took the gap between two steps the same
way, and that one decides jacks, crossovers and freezes, so it now asks the
timing for both moments.

Nothing detects tempo changes on its own. The meas... (continued)

716 of 716 branches covered (100.0%)

Branch coverage included in aggregate %.

106 of 106 new or added lines in 4 files covered. (100.0%)

3563 of 3563 relevant lines covered (100.0%)

3.0 hits per line