Sylpheed/docs/re/plate-pulses-via-ptbtn00f.md

✅ The plate does pulse — but ptbtn00 is not what loops. ptbtn00f is, on a declared 120-unit cycle

Status: ✅ measured for the pulse; ✅ decoded for the period's source; ❔ the per-frame series does not exist. 2026-09-02. Instruments: ⟨disc⟩ for the loop length, ⟨capture⟩ for the pulse itself.

Answers the port's question — does the PRESS Ⓐ plate pulse in the running game, and with what period? — and corrects the premise it was asked under.

---

The correction first, because it changes where to look

The port asks whether ptbtn00's declared 0:0 214:0 236:255 238:255 244:0 loops at t = 244. It does not. ptbtn00 ramps up, holds, extinguishes, and stays out.

The pulse is a different element. ptbtn00f — the plate's focus/glow variant, reached through focus_link and carrying no top-level element of its own — declares a 120-unit loop ⟨disc⟩.

That is why a reader looking only at ptbtn00 sees a one-shot: the looping element is the one that a declaration-order walk never reaches. 📌 It is also the same element that needed the by-name accessor in ui_layout — ptbtn00f.t32 is in build.sprites with nothing pointing at it — so this is the second time that element has been invisible to a walk that only follows declared elements.

The measurement that exists

title-plate-delay-measured.md, from two boots on 2026-08-29:

"its pulse is the focus record ptbtn00f, measured here at 2.12 / 2.19 / 2.34 / 2.31 s over four intervals, mean 2.24 s"

Cross-check against the disc, which is the part that makes it more than a stopwatch reading: 120 declared units at the rate law (clock-rate-follows-the-vblank.md: units/s = display refresh rate) is 2.000 s at 60 Hz. Measured mean 2.24 s — 12 % long, in the direction and roughly the size Canary's slower-than-real pacing produces. Declared period and measured period agree.

So: yes, it pulses, and the period is 120 units.

⚠️ What this is NOT, stated plainly

The port asked for a per-frame series, and this is not one.

• Those four intervals come from a screenshot probe — the weaker of the two instruments, and one carrying a wall-clock duration off an emulator whose pacing is load-dependent. It is the instrument class that has cost this corpus four withdrawn timing claims.
• The strong instrument — per-frame vertex alpha off the guest's own buffer, the one that settled the splash — has never reached this screen. Five capture attempts, each blocked differently: wall-clock timeout, frame cap, a self-matching pkill, and the fact that the title sits past the 137.7 s attract movie at ~1.3–1.8 presents per decoded movie frame.

For the port: the fact and the period are answerable now — a 120-unit cycle, not a 244-unit one, driven by ptbtn00f and not ptbtn00. The trajectory within a cycle is not, and I will not infer its shape from the declared keyframes when the whole point of the splash exercise was that only a capture could confirm the shape.

Refutation attempt, recorded per the adversarial duty

Target: the port's framing that the question is "whether the timeline loops at 244 or something else drives it."

Result: the disjunction is REFUTED — both halves are wrong about ptbtn00. It does not loop at 244, and nothing else drives it; a different element loops, on 120. The port's instinct not to infer from "PRESS START prompts usually blink" was right, and the answer turned out to be one element sideways rather than one timing constant away.

Reach

⟨disc⟩ for the 120-unit loop, so it generalises to every screen carrying that element. ⟨capture⟩ ×2 boots for the pulse, at four intervals, via the screenshot probe. No per-frame series, on any instrument, for this element — that gap is real and is what the next title-reaching capture should spend itself on.