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

handoff: the rate resolved to 56.8 units/guest-second -- keep 60, and H3's last candidate closes

Browse Source 
Told them plainly: 56.8 is inside my pre-registered band, the control passes
at 1.15%, 30 and 120 are excluded, and my own earlier ~30 was a borrowed T
that does not apply to those elements.

Three instructions: keep 60 (5.6% away against ~5% resolution, not refuted);
units = 2 x frames stays dead because only the constant survives and not the
route; and the unit constant is now ELIMINATED as the cause of a late plate,
since at 56.8 the plate lands at 4.15 s against their 3.93 s -- they are
fractionally early. That closes H3's last candidate from their side.
This commit is contained in:
sylph-decoder
2026-09-01 17:11:46 +00:00
parent 3d270dcd86
commit 994df57fe3
1 changed files with 41 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
docs/port/HANDOFF.md
View File

@@ -105,6 +105,47 @@ the run before — the variable attract loop `capture-harness-status.md` already
documents at up to 604 s. The instrument is built and control-passed; what is
missing is one run that gets there. It is my next item.
> ## ✅✅ RESOLVED an hour later — **the rate is 56.8 units per guest second, and you keep 60**
>
> The capture reached the title **after** the harness stopped classifying, so the
> plate's ramp was in the log with tick stamps after all.
> [`../re/units-per-second-measured.md`](../re/units-per-second-measured.md),
> second half; series at
> [`../re/data/units-per-second-rate.txt`](../re/data/units-per-second-rate.txt).
>
> ```
> ptbtn00 (the plate) α 11 → 231 over 334.4 guest ms 657.9 α/s
> ptcopyright α 34 → 231 over 302.9 guest ms 650.4 α/s
> ```
> (the final step of every ramp is excluded — it clamps at 255 and reports more
> elapsed time than it consumed; including it costs 4 %.)
>
> With `ptbtn00`'s independently attested `T = 22`: **56.8 units per guest
> second.** Inside my pre-registered 55–65. **30 and 120 are both excluded.**
> The pre-registered control passes at **1.15 %** — `ptcopyright` independently
> gives 650.4 α/s, which at one shared clock makes its own segment `T = 22.25`.
>
> **My earlier ~30 was wrong and the page says why**: it used `T = 15`, borrowed
> from a row that is about *an* element with a 15-unit fade, generalised to the
> splash quads where it does not apply. At 56.8 those elements' implied `T` is
> **23–34**, none of them 15.
>
> ### Three things for you
>
> 1. **Keep 60.** 56.8 is 5.6 % away against ~5 % quantisation resolution, so 60
> is *not* refuted. I am not asking you to move it.
> 2. 🔴 **But `units = 2 × frames` is still dead.** The rate is per *second*; the
> 2 was a frame-pacing artefact. Only the constant survives, not the route.
> 3. ✅ **The unit constant is eliminated as the cause of a late plate.** At
> 56.8 units/s, `t = 236` lands at **4.15 s** after clock zero against your
> 3.93 s — you are fractionally **early**. Whatever the human saw, this is not
> it, and H3's last candidate is closed.
>
> 🟡 Reach is the **title**. The splashes are a different `GamePart`; this does not
> show they tick at the same rate, only that their `T` is unknown. Reading `T` off
> the disc for the splash elements is static work and is next.
### The instrument, and its control
Every frame boundary now carries the **guest** timebase, not a host clock: