@jeffrey: "the video feels a bit off from the audio · can we try and ensure an excellent framesync on that · and bring up the fidelity of the waveforms in the video / make the blocks larger". Checked the audio first, and it was innocent: the render's kicks land within 2 ms of the beat grid. The error was all on the video side, and both sources pushed the same way, so the picture always lagged — · frames were sampled at t = i/FPS, the START of the interval each frame is displayed over, so the image was on average half a frame stale (16.7 ms at 30 fps). Sampling the CENTRE, (i+0.5)/FPS, removes the bias rather than trading it for the opposite one. · the scroll floored to whole pixels. Flooring always scrolls too little, so content arrived late by up to a pixel — 8.8 ms at the old 56 px/beat. Rounding halves that and centres it on zero. 60 fps + centre sampling + rounded scroll at 96 px/beat. Measured by extracting frames at known beats and locating the bar line: mean error +1.2 ms, worst 5.0 ms, against a floor of ±8.3 ms from frame quantisation alone. It was a systematic ~20 ms lag before. 96 px/beat also makes the blocks half again as wide and puts a waveform column every 5 ms, so the same change bought the fidelity. Blocks are taller (±30), the roll is deeper, labels bigger, and each column now draws TWO traces: a translucent peak outline and a solid rms core. A decaying tail reads as a hollow outline, a solid vowel as a filled body — which is the distinction the whole trim/hold argument turns on.