Files
Sylpheed/docs/re/structures/plate-pulse-measured.md
sylph-decoder b6f0cf3fb2 re: RETRACT -- a Canary config dump is the FILE, not the run
Refuted my own evidence with a direct test. The A-press fault page cited the
faulting run's dumped logged_profile_slot_0_xuid = "" as proof no profile was
signed in. Xenia prints its config dump BEFORE applying command-line overrides:
in a run launched with --apu=sdl --hid=file --mute=true --log_mask=13, the dump
says apu="any", hid="any", mute=false, log_mask=0. Four for four.

So the dump is a statement about xenia-canary.config.toml and nothing else, and
this page cannot know the faulting run's profile state. Anything in the corpus
citing a config dump as evidence of what a run did is making the same mistake;
to know a run's settings, record its argv.

Survives: the mechanism (swallow -> unbounded pump -> failed allocation ->
fault), which rests on the [RE-INPUT] counter and the crash dump's registers;
and canary-scripted-input-traps.md section 3's measured sign-in-dialog claim,
which has a capture behind it.

Also records the port's base-plus-glow mechanism for the plate, which explains
why the pulse floor is 714 rather than the plate-absent 159 -- ptbtn00's fade at
t=244 is an exit ramp so the base holds at 255 while the screen is held, and
ptbtn00f's 0->80->0 glow draws over it. Marked as agreeing with the measurement,
not confirming it: their renderer is not an oracle. It does rule out a glow-only
plate, which could not produce a non-zero floor.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
2026-08-30 07:52:14 +00:00

5.7 KiB
Raw Blame History

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=236238, 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).

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

⚠️ That third one is the reason the result is readable at all: the plate-absent floor is 159, not 0 — 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.