fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

handoff: F6 -- start the sweep just before the plate, and drop my frames-based rates

Browse Source 
Delivers the two numbers the port needs (lead 0.79-0.80 baselines, period
13.93 baselines, each reproduced across two captures) and withdraws unit 8's
0.514 units/frame: captured frames differ 1.947x between runs, which is the
size of the port-vs-decoder disagreement we had left standing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-02 19:21:41 +00:00
parent 7b3c83858d
commit 36cebf753a
1 changed files with 24 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/port/HANDOFF.md
View File

@@ -6032,3 +6032,27 @@ reproduced 4/4, so that page's "retry whole boots" does not obviously apply.
Detail: [`docs/re/structures/title-a-press-fault.md`](../re/structures/title-a-press-fault.md).
## F6 answered — the sweep leads the plate, and frame counts don't travel
`docs/re/f6-unit9-sweep-period-and-onset.md`, commit `ad83664`.
**Start the sweep shortly before the plate's fade-in, not at `t=0`.** At `t=0` it
is ~200 title units early. Measured lead: **0.798 / 0.791 baselines** across two
independent captures (0.9% apart) ≈ **40 title units** — under a second, which is
why the human read the sweep and the plate as simultaneous. Loop period is
**13.93 baselines** (13.905 / 13.953, 0.35% apart).
⚠️ **Any rate I have given in captured frames is withdrawn.** The same animation
took **1168** frames in one capture and **600** in the other (**1.947×**), the
baseline moving **1.953×** with it — frames are presents and the rate is per-run.
That includes unit 8's **0.514 units/frame**: a 1.95× run-to-run factor is
exactly the size of the port-vs-decoder gap we could not explain, so the 0.514
was most likely a pacing artefact of one capture. The port running the leaf at
1.0× is not the discrepancy it looked like.
🟡 Unresolved and deliberately not smoothed: within one capture the title clock
reads **1.0 units/frame** (`ptcopyright`, 22-unit ramp) and **0.571** (plate,
declared 12-unit ramp) — 1.75× apart. Either a declared ramp is misread or the
two are **not on one clock**, i.e. `clock: "shared"`. That is F4. Ratios above
need no clock and stand; the title-unit conversions wait on it.