From eeb4473b4f723de8d7bf7aae287ed3657a823643 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Tue, 1 Sep 2026 19:15:34 +0000 Subject: [PATCH] re: the port's 12-unit bracket does not exclude 120 -- its low end is the sampler's floor The port kept 60 on a stated constraint: the transition quad is declared black for 12 units, measured at 0.14-0.30 s, giving 40-86 units/s, so 60 is in and 120 is out. Attempted to refute it, and it does not hold. Two reasons, either sufficient. The low end is the instrument's floor. title-plate-delay-measured.md says of that number, in its own words, "at a sampling resolution (0.125 s) that cannot do better". 0.14 s IS one sample. At 120 units/s, 12 units is 0.100 s, which a 0.125 s sampler reports as roughly 0.14 s -- exactly the value read as excluding it. The 86 units/s upper limit is an artefact of dividing by a floored duration. And a wall-clock duration off Canary is not independent of the unknown. Apparent units/s = true units/s x speed factor, and the speed factor is precisely what makes the three routes disagree. The bracket says "if Canary ran at real time, 40-86" and whether it did is the question. What survives is the declared side, and it is a disc fact worth keeping: the transition opens over 12 units, independently confirmed as 6 frames by screen-transitions.md's 255/6-per-frame ramp. That leg has no wall clock in it and is real evidence -- for units per FRAME, which was never in dispute. This does not argue for 120. Nothing supports 120 either. It removes a reason for excluding it, and my position is unchanged: the value is authored until the content-hash experiment runs. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t --- docs/re/guest-frame-rate-WITHDRAWN.md | 47 +++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/docs/re/guest-frame-rate-WITHDRAWN.md b/docs/re/guest-frame-rate-WITHDRAWN.md index 79a8ba19..78c1259d 100644 --- a/docs/re/guest-frame-rate-WITHDRAWN.md +++ b/docs/re/guest-frame-rate-WITHDRAWN.md @@ -105,3 +105,50 @@ once per present or once per two. The splash alpha data needed for that is in th **Nothing yet, and I have told them so.** Their 60 is no longer *supported* by me, but it is not *refuted* either — one route favours 120 and another favours 56. A port that changes on this page would be acting on my second guess in one day. + +## Refutation attempt on the port's independent constraint — it does NOT exclude 120 + +The port offers a bracket as its stated reason for keeping 60: the transition quad +is **declared black for 12 units**, the capture measured that plateau at +**0.14–0.30 s**, so `12 / 0.30 … 12 / 0.14` = **40–86 units/s** — 60 inside, 120 +outside. They call it frame-free and note it survives everything retired here. + +**Frame-free it is. Independent it is not, and the exclusion does not hold. Two +reasons, either one sufficient.** + +### 1 — the low end sits ON the instrument's floor + +`title-plate-delay-measured.md` says of that very number, in its own words: + +> *"Consistent, at a sampling resolution (**0.125 s**) that cannot do better."* + +A 0.125 s sampler cannot report an event shorter than about one sample. **0.14 s +is one sample.** So the observed low end is not a measurement of the event — it is +the floor, and every true duration from ~0 to ~0.14 s produces it. + +At 120 units/s, 12 units is **0.100 s**. Sampled at 0.125 s that is observed as +one sample and reported as ≈0.14 s — **exactly the low end that was read as +excluding it.** The bracket's upper limit of 86 units/s is an artefact of dividing +by a floored duration. + +### 2 — a wall-clock duration off this emulator is not independent of the unknown + +Every duration measured off Canary is `true_guest_duration / speed_factor`, so +apparent units/s = true units/s × speed. **The speed factor is the exact unknown +that makes all three routes disagree in the first place**, and a constraint built +on a wall clock inherits it rather than escaping it. The bracket says "if Canary +ran at real time, units/s is 40–86" — and whether it did is the question. + +### What survives, and it is worth keeping + +The *declared* side is solid and is a disc fact: the transition opens over +**12 units**, and `screen-transitions.md` independently confirms it as **6 frames** +(`255/6 per frame after a half-step start`), which is the already-✅ 2 units per +frame. **That leg has no wall clock in it at all** and is real evidence — for +units per *frame*, which was never in dispute. It says nothing about units per +second. + +⚠️ **So the port is keeping 60 for a reason that does not support it.** I have told +them so. That does not mean they should change it — nothing supports 120 either, +and my position is unchanged: the value is authored, not measured, until the +content-hash experiment runs.