Twinned from https://github.com/cfsh/ninefold/issues/488 by tools/beads/import_github.py's reconcile pass.
From the playtest sitting 2026-08-04, F5 build ca7a756. Evidence: [capture-3](https://github.com/cfsh/ninefold/blob/6334c0a49699b4e877cc48eccc3e0913c06ae343/playtest-logs/2026-08-04-ca7a756/capture-3.png).
Aedan's words, contrasting the two playback surfaces:
> "When I play the song in the song view, I can see the playhead gliding across correctly. […] But when I go into a pattern and press □ to play the pattern, the playhead doesn't animate smoothly. It appears for a couple of frames and stutters around. It doesn't glide across."
So: song view = smooth, pattern view = stuttering. The song-view path already does the right thing, which makes this a good candidate for reusing that interpolation rather than writing new motion.
Likely shape: the song playhead is driven by a per-frame interpolated position (PianoRoll carries a draw-offset glide for R2 octave jumps, so the smoothing machinery exists), while the pattern playhead is redrawn only on step boundaries — at typical tempos that is a handful of discrete jumps per bar, which matches "appears for a couple of frames and stutters".
> "Doesn't have the little triangle on top anymore. I don't know if it ever had that for the song view."
He is unsure whether the song-view playhead ever had the small triangle marker at its top, so treat this as a question to answer, not a confirmed regression: check whether the marker was dropped at some point or only ever existed on the pattern playhead. If it never existed there, say so and close the sub-item; if it regressed, restore it.
This is distinct from #394 (auto-scrolling the song window to *follow* the playhead). This issue is about how the playhead itself is drawn and animated within the view it is already in.
Refs #394
None.
No comments.
