Split screen: play-pattern button doesn't toggle, notes header flickers on vertical scroll, and the playhead doesn't animate nf-lqg7 ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/517 by tools/beads/import_github.py's reconcile pass.

aedanpope, 2026-08-04, with a screenshot on #508. Split screen only — *"This all renders / animates fine in the same instance of ninefold if I toggle back to single screen."* Filed unclaimed; split out of #508 because that PR turned out to fix none of it.

The three symptoms, verbatim

1. *"the play pattern button doesn't toggle when pressing square (even though the audio loops)"*
2. *"The notes header row 'keys hum' etc vanishes momentarily when scrolling the notes editor vertically."*
3. *"the Playhead does show in the notes / pattern editor, but it doesn't animate, it's in a single position. Actually as I move the editing cell focus around, the playhead does move in jumps / leaps to the right."*

(3) is the diagnostic one: a playhead that is *correct* the instant an unrelated event repaints the roll is not a playback bug. The step value is advancing fine — the roll is not being repainted. (1) is the same shape from the other side: PianoRoll.OnPlayheadMoved is what sets the play button's text, so a button stuck on "▶ play pattern" while audio loops says that handler is not reaching the visible control either.

⚠️ Read this before probing it

A shot step forces a repaint, so screenshot-based sampling cannot see this bug. Aedan called it: *"maybe the probe is causing enough of an update for the animation to show for u"* — and he was right. Consecutive shots differ whether the roll animates at 60fps or repaints only when the probe pokes it. Every "it animates fine" measurement on #508 was taken with that hole in it.

Two instruments on fix/song-mode-playhead-probe exist for this and read without perturbing:

• PianoRoll.DrawTicks — counts actual _Draw invocations. Sample twice across a wait_ms gap with no shot anywhere in the probe. ~33/sec means animating; a handful means frozen.
• PianoRoll.PlayheadAdvancing — off + advancing yes is #102 correctly hiding a live playhead; lit + advancing no is a frozen one. Identical pixels, opposite bugs.

The lead: window size changes which button answers

Not reproducible at 1920x1080 — 33 repaints/sec, button text toggles correctly. Aedan's window is 1906x807. Same probe, only the size differing:

``` 1920x1080: focus "▶ play pattern" -> @Button@115 then "⏹ stop" OK, PlayheadShown = lit Loop 1906x807: focus "▶ play pattern" -> @Button@38 (!) then "⏹ stop" OK, PlayheadShown = off Song ```

At his size the text "▶ play pattern" resolves to a different button, and pressing it starts Song playback rather than Loop. Two buttons answer to overlapping text and which one you get depends on the layout the window size produces. That is on symptom (1) directly, and it is the only thing found so far that behaves differently at his size.

Worth checking early: how many play buttons are live in the tree in split screen, whether the hidden screen's controls are still focusable (single-screen.json records that "Godot will happily focus a hidden control, and that failure looks like a dead d-pad rather than an error"), and whether PianoRoll._playBtn is the one on screen.

Also asked, and not done

> *"ideally we'd move the Play Pattern button up next to change keys instrument in this view"*

A layout change in the same area; probably belongs with whatever fixes the above rather than on its own.

Unknowns worth getting from Aedan first

• Exact window size, and whether layout is Auto or explicitly forced to split. If Auto, size is the variable.
• Whether the play button misbehaves the same reached by d-pad versus clicked.

Related: #496 (the original playhead report), #508 (the PR that fixed none of this and carries the instruments), #453 (one-screen layout), #102/#105 (the playhead gate, confirmed correct as-is).