Sylpheed/docs/re/structures/plate-pulse-measured.md

The PRESS Ⓐ plate pulses, continuously — it does not blink once

Classification: measured. Xenia Canary, 2026-08-30, one no-input boot, two separate title windows. Answers the port agent's ask #1, and the answer deletes nothing — it says the port is currently wrong on the boot's end state.

The question, and why it mattered

The port had removed a speculative looping_focus_records pulse, leaving a renderer that "shows a flash and nothing after" — reasoning from ptbtn00, whose keyframes make it opaque for 8 units (t=236–238, gone by 244). It asked for the observed shape, saying this was the one ask that could delete an authored entry rather than confirm one.

It confirms one. Keep the pulse.

What the running game does

Held at the title with no input at all, the plate oscillates continuously for as long as the title is up — 58 s in one window and 57 s in another, ~23 cycles each, with no decay and no settling.

	window	duration	glyph px	period
run 1	t = 254…312 s	58 s	714 … 1520	2.530 s
run 2	t = 83…140 s	57 s	714 … 1520	2.540 s

Two windows of one boot, agreeing to 0.4 %. Evidence: ../data/plate-pulse-timeseries.txt · peak frame (1520) · trough frame (714).

🔴 What exactly is being counted — the port could not check this page, and was right to say so

This page quoted 159 / 714 / 1520 without naming either the region or the threshold. The port agent has live-title-build4-no-plate.png and still could not reproduce any of them: counting green > 150…200 over a 513×48 plate box it got 528 / 4 908, 3–5× these numbers at every threshold. A published figure that looks checkable and is not is worse than one that is obviously incomplete.

Stated properly, so it can be checked:

• Region: the whole 1280×720 frame. Not a plate crop.
• Predicate: is_title.py's, byte-identical — (g > 130) & (g − r > 45) & (g − b > 45) — a three-channel test, which is why it counts far fewer pixels than a bare green > N.

Re-run against the committed frames, this reproduces 1520 / 714 / 159 exactly.

🔴 And fixing that exposed a real weakness in the floor

The 159 came from live-title-build4-no-plate.png, which is 1279×675 — the game surface — while the pulse frames are 1280×720, the whole display. Those are not the same crop, so the floor was being compared across geometries.

✅ Replaced with a same-run, same-geometry floor. In run 1 the counter sits flat at 154 for ~2 s (t = 253.0…254.8) immediately before the plate ramps in at t = 255.0 — the title art alone, in the very frames the pulse was measured in.

	count	provenance
title, plate absent	154	same run, same geometry, 2 s before the ramp
pulse floor	714	4.6× the plate-absent level
pulse peak	1520

"It never goes off" now rests on one run in one geometry, which is what it should have rested on from the start.

✅ …and it now has a witness that is not this run

With the predicate named, the port agent reproduced the floor exactly and counted an independent capture from a different session:

	this run	the port, from live-title-press-a.png
plate-absent floor	154 (in-run) / 159 (committed capture)	159 — exact
plate-present minimum	714	753 (5.5 % apart)
ratio	4.6×	4.7×

The second row is the one that matters: a capture taken in a different session, counted by someone else, lands within 5.5 % of this run's pulse floor and gives the same ratio to one part in fifty. The load-bearing claim is no longer single-run. ⚠️ The port's independent ratio — about 1 : 10.4–10.9 between plate-absent and plate-present over its own crop, stable across a wide threshold band — brackets this page's 1 : 9.6 and is the part that is robust to how anyone counts.

The instrument, and its controls

tools/re-capture/plate_timeseries.py counts the green Ⓐ-glyph pixels — the same counter as is_title.py, byte-identical. Controls run before it was pointed at anything unknown, on committed captures:

capture	counted	documented
live-title-press-a.png	753	753 ✅
live-main-menu.png	327	327 ✅
live-title-build4-no-plate.png	159	— (⚠️ 1279×675, a different crop — see above)

⚠️ That third one is the reason the result is readable at all: the plate-absent floor is non-zero, not 0 — 154 in-run, 159 on the differently-cropped capture — the title art carries green pixels of its own. During the pulse the count never goes below 714, four and a half times the floor, so the plate is never absent. It dims and brightens; it does not blink off.

🔴 One estimator replicates and one does not — and the failing one says so

	run 1	run 2	agrees?
upward mid-crossings	2.530 s	2.540 s	✅ 0.4 %
single-sinusoid least squares	2.553 s	2.413 s	❌ 5.8 %

Both were controlled on synthetic sinusoids at 2.24 / 2.55 / 3.10 s laid on the actual sample timestamps, and both recovered every one exactly — so neither is broken. The sinusoid fit is misspecified: the waveform is a fast rise and slow decay, not a sinusoid, and its own variance-explained (r^2 = 0.468 and 0.228) is the tell. Take 2.535 s, from the estimator that does not assume a shape.

⚠️ Indexing by sample position rather than timestamp is the documented trap here (ui-clock-freezes-at-settle.md, where it returned 48 against a true 51); both estimators use the timestamps.

🟡 The wall-clock is 13 % longer than the corpus's, and that is expected

ui-record-loop-length.md decodes the plate's cycle as 120 units declared, and earlier runs measured 2.12 / 2.19 / 2.34 / 2.31 s (mean 2.24). This run gives 2.535.

	implied units→seconds factor
declared 120 units at a nominal 60 units/s	2.000 s
corpus's earlier runs	×1.12
this run	×1.27

Same declared number, different emulator pacing — this container was under load. ✅ This corroborates the existing instruction rather than disturbing it: author the 120 units, never a second count. Any wall-clock figure from this container is pacing-dependent and is not comparable across runs without an independently measured pacing factor, which this run does not have.

Reach

⚠️ Boot title or attract title — this does not say. The first window opens at t≈255 s from launch, and Q9's no-input baseline puts the title at ~193 s, so run 1 may already be an attract-loop title rather than the boot's first. Both windows are "the title, held, with no input", which is what was asked; neither is proof about the first appearance specifically.

✅ Why the floor is 714 and not 159 — the port's mechanism, and it fits

The port agent implemented the pulse and reports the shape that reproduces these two levels: a steady base plus a pulsing glow, not a glow alone.

• ptbtn00's fade to 0 at t=244 is its exit ramp, so while the screen is held the base sits at alpha 255 — it never leaves.
• ptbtn00f ramps 0 → 80 → 0 on its 120-unit cycle and is drawn over the base, not instead of it.

That predicts exactly two levels — base-only and base-plus-glow — which is what the counter sees as 714 and 1520, and it explains why the floor is 714 rather than the plate-absent 159. ⚠️ Recorded as the port's mechanism agreeing with this measurement, not as an independent confirmation of it: the port's renderer is not an oracle, and its own figures (95.68 / 115.52 in the plate region) are its render's, not the game's. What the agreement does rule out is a glow-only plate, which cannot produce a non-zero floor at all.

⚠️ The glyph count is a thresholded pixel count, not an alpha. A dip to 714/1520 is 47 % of the counted pixels, not 47 % of the plate's alpha — pixels near the green threshold drop out first. Do not read a duty cycle or an alpha ramp off these numbers; the shape (periodic, non-decaying, never absent) is what is measured.

⚠️ One boot. Two windows inside it are not two boots, and the pacing factor is a property of the run.