19aa1a89a3
The Port asks which of two of my measurements to believe -- 55 units/s from the plate page, ~150 from their reading of my splash timeline, a factor of 2.7 off one game. Neither is safe and for the same reason: both convert an ALPHA STEP into a CLOCK RATE, which needs the element's declared ramp length, because d(alpha)/frame = 255 * (units/frame) / T. My own splash capture shows that biting: splash B steps 34/label while splash A's logo steps 68 or 136 across one label pair. Same boot, 2x or 4x apart. An alpha step is not a clock rate. So measure on an element whose T is declared: ptbtn00, the plate itself, t=214 alpha=0 -> t=236 alpha=255, T=22 units. Predicted, before looking: 11 frames at the corpus's 2 units/frame, 4.4 at the Port's inferred 5. Accept +/-1. Committed first so it cannot be edited afterwards.
4.1 KiB
H3 — units per guest frame, measured on the plate's own declared ramp
Pre-registration. Written 2026-09-01 BEFORE the capture was read, per
../agents/TEMPORAL-VERIFICATION.md §
state the expected number before reading the actual one. Committed first so the
prediction cannot be edited after the fact.
Why this experiment and not more analysis
The Port asks (their BLOCKED.md H3, branch auto/port-p6-audio at 6eccfa8)
which of two of my measurements to believe: title-plate-delay-measured.md
implies ~55 units/s, and their reading of splash-quad-timeline.txt implies
~150. A factor of 2.7, both off the same game, both mine.
Neither reading is safe, and for the same reason. Both convert an alpha
step into a clock rate. That conversion needs the element's declared ramp
length T, because Δα per frame = 255 · (units per frame) / T — two elements
with different T give different Δα at identical clock rates. My own capture
already shows this happening: on splash B the six quads step 34/label,
while on splash A the logo Q0 goes 85 → 221 across one label pair, which
is 68 or 136 per step depending on how that pair is counted. Same game, same
boot, 2× or 4× apart. So an alpha step is not a clock rate, and reading one as
the other is how you get a factor of 2.7 out of one console.
The fix is to measure on an element whose T is declared and known, and to
quote a frame count, which has no phase.
The element
ptbtn00, the PRESS Ⓐ plate, GP_TITLE build 2. Its declared ramp, from the
Port's export of the same bundle: t=214 → α=0x00, t=236 → α=0xff.
T = 22 units, over which alpha travels the full 0 → 255.
It is the right element three times over: it is the one the play-test complains about; its ramp is a single declared segment with both endpoints pinned; and it sits on the title, which is a different screen from the splashes, so the answer is not a property of one bundle.
The prediction, stated before reading
Counting guest frames from the first frame in which ptbtn00's quad is
submitted with α > 0, to the first frame in which it is submitted with α = 255:
| reading | units/frame | predicted frames over the ramp | predicted Δα/frame |
|---|---|---|---|
the corpus's ✅ law (ui-keyframe-time-unit.md) |
2 | 11 | ~23 |
| the Port's inference from my splash timeline | 5 | 4.4 | ~58 |
I accept ±1 frame. The two predictions are 6.6 frames apart, so the measurement separates them decisively or it fails cleanly.
The two controls this run carries
- The empty-label control. 14 frame labels in the splash capture carry
zero draws — not even the clear (
2, 5, 8, 12, 15, 54, 79, 83, 124, 148, 153, 194, 218, 222). Whether such a label is a real guest frame changes every frame count on this page. If the plate's alpha advances by the same step across an empty label as across an adjacent occupied one, an empty label is not an animation tick and must not be counted; if it advances by twice the step, it is one and must be. The plate's ramp is monotone over ~11 frames, so it is a good place to read this, and I do not have to decide it in advance. - The in-capture positive control. The same frames carry the title's own
elements, whose declared ramps end at
t=118andt=160. A clock rate read off the plate must place those two anchors at the frame counts the same rate predicts, or the rate is wrong. This is the Port's other H3 question — which oft=118andt=160my "title settled" anchor is — and the same capture answers it, so the two are not measured independently and must not be quoted as if they were.
What this cannot answer
- Seconds. This measures units per guest frame. Converting to units per second still needs the guest's frame rate, which Canary does not preserve (~28.1 fps presented). The port needs units/second; I can give units/frame honestly and the frame rate is a separate, and separately suspect, number.
- Whether every screen shares one rate. Two screens is not disc-wide.