Sylpheed/docs/re/f5-a-press-snaps-the-plate.md

F5 — Ⓐ snaps, and it snaps the WHOLE title

🔴 CORRECTED 2026-09-02, same day. This page first said Ⓐ snaps only the plate and leaves the artwork animating, and used that to refute clock: "shared". That was wrong. A pre-registered wider test (f5-artwork-window-prereg.md) refuted it: the artwork snaps too. The cut finding stands and is stronger; the artwork half is reversed. See "What went wrong" at the bottom — the error is instructive.

Question: when you press Ⓐ during the title's build-in, does the animation jump straight to finished, or does it speed up?

What the human looks at: press Ⓐ while the title is still building. Pass for snap = the PRESS Ⓐ plate is simply there, with no fade. The artwork behind it keeps animating either way.

What this does NOT cover: what Ⓐ does once the title has settled (it is accepted — see the miss below), and the sting question in F3.

Instrument: ⟨capture⟩ ×3 — one press run (f5), two no-press controls (f6, f6b) captured earlier for F6.

✅ Measured — it is a CUT, not an acceleration

The brief's discriminator: an acceleration shows intermediate alphas, a cut shows none. Aligning all three runs by the sweep's own position (a phase-free clock readout, not a frame number):

plate's alpha, frame by frame, from its first draw
no-press control f6b	23 · 46 · 69 · 92 · 115 · 139 · … ~11 frames of ramp
press run f5	255 — one frame, nothing before it

Zero intermediate values against eleven. The human's "looks more like a snap" was a prior, and the measurement agrees with it.

✅ The control is what makes this readable, and it nearly went the other way

My first look at f5 found four elements ramping out right around the press and I could have called that the effect. The controls say otherwise: at sweep x = -1.42 all three runs agree quad for quad —

f5  f445 | 8ECA:-1.00 a54  8ECA:-0.90 a15  EAC3:-0.82 a29  8154:-0.74 a6
f6  f781 | 8ECA:-1.00 a54  8ECA:-0.90 a15  EAC3:-0.82 a29  8154:-0.74 a6

— identical. Those exits are the ordinary build-in and the press did not cause them. Only the plate differs.

🔴 This refutes clock: "shared" — on F4's own stated discriminator

F4 set the test: press Ⓐ early and watch the artwork, not the plate. Snapping the artwork means one shared clock; leaving it animating means Ⓐ only forces the plate visible.

The artwork keeps animating. Across the press, the sweep's position and alpha and the artwork's exit ramps continue frame-for-frame identically to the control (step −10 alpha/frame in both f5 and f6b; f6 runs −5 because that capture paced at half rate, which the ratio removes).

So the title is not one clock. Ⓐ forces the plate and leaves the artwork's timeline alone.

⚠️ Reach. The artwork half rests on a 5-frame window — frames 446–450, the only stretch where the press had landed and artwork was still animating. Everything else on screen was already at α255 and cannot discriminate. Pressing Ⓐ right at the sweep's gate (t≈70–100) would widen that window and is the experiment that would harden it.

🔴 The first attempt missed, and the probe said so

Wall-clock timing put press 2 at log frame ~1217 when the title had settled at ~653: Ⓐ was accepted instead, and UI draws stopped. The build-in is only ~180 log frames wide and pacing varies 2×, so blind delays cannot hit it.

The fix is the one the brief prescribes for F1: gate the press on an observable. f5_snap_or_accelerate.sh now waits for the sweep's texture page to appear — which is the parent's declared gate at t=70…100 — then counts a fixed number of frames. It hit the window first try.

Not settled

• The element called "the plate" is still identified by screen position only. Its behaviour matches the plate (appears on Ⓐ, pulses after), but it is not named. The 1.7× clock conflict against t≈236 is unresolved.
• Whether Ⓐ snaps a third clock, or reveals the plate by a route with no clock at all — a cut is consistent with both.
• The 5-frame reach above.

---

🔴 The correction — the artwork snaps too

Pressing Ⓐ at the sweep's gate (t≈70) instead of 40 frames later leaves ~40 frames of artwork still animating. Pre-registered prediction: the artwork continues identically to the control. It does not.

f435 | 8ECA:-1.00,a55   EAC3:-0.83,a27   8154:-0.74,a27      artwork mid-ramp
f436 | 8154:-1.54,a255  EAC3:-0.90,a255  8154:-0.54,a255     gone; settled set at full

Three elements mid-fade-in vanish in one frame, and the settled set appears at α255. Most telling: the sweep enters at α255 with no ramp, where the control ramps it 17→255 over ~15 frames as its parent's declared t=70…100 requires. The title clock jumped past t=100.

It did not jump past 250 — ptloop01's exit ramp would then have taken the sweep back to α0, and the sweep is at 255. So Ⓐ advances the title clock into [100, 238], consistent with the settle window [160,236] that ui-clock-freezes-at-settle.md already found the clock freezing in.

So clock: "shared" is NOT refuted. Ⓐ advances one clock and the artwork rides it. F4's discriminator, run properly, goes the other way.

What went wrong, because it is a trap worth naming

The press takes ~11–12 frames to take effect, and I measured inside that gap.

run	press sent	effect visible	gap
f5 (late press)	f445	f456	11
f5-early	f424	f436	12

My "5-frame window, frames 446–450, artwork identical to control" sat entirely inside the latency gap. Of course it matched the control — the input had not been acted on yet. And by the time it was, the artwork had finished its ramps on its own, so there was nothing left to snap and nothing to see.

The window was not merely small. It was positioned where the effect cannot appear, which no amount of enlarging would have fixed — only moving the press earlier did. I stated the 5-frame reach honestly and still drew a conclusion the data could not carry.

A control matched at the wrong instant is not a control.