diff --git a/authored/timing.json b/authored/timing.json index 7d54c884..e19f31db 100644 --- a/authored/timing.json +++ b/authored/timing.json @@ -62,34 +62,45 @@ ], "press_start/ptbtn00": { "record_element": "ptbtn00f", - "period_units": 105, + "period_units": 120, "kind": "chosen", "why": [ - "105 units = the element's own group, start to end, under the CORRECTED record", - "layout: its keyframes now run t=0 (alpha 0x00) through t=105 (alpha 0x00), a", - "closed cycle with every pose timed.", + "120 units, and it is DECODED rather than chosen -- but it is still written", + "here because the field is not in the pinned crate yet. DELETE THIS the day a", + "tag exposes it and the exporter can emit it.", "", - "IT WAS 129, AND THAT NUMBER IS NOW INDEFENSIBLE: it was the last timed", - "keyframe (105) plus `exit_ramp_units` (24), and exit_ramp_units has been", - "DELETED because the untimed final keyframe it stood for does not exist. A", - "period built from a deleted constant cannot stay.", + "A nested record is itself a RATC bundle with its own header, and that header's", + "+0x08 IS THE LOOP LENGTH -- the same field `ui_header_time_disc` already tests", + "as an animation length at the top level. A record's keyframes need not fill", + "it, and the slack is a hold at the final pose. `ptbtn00f` is 105 UNITS OF RAMP", + "INSIDE A 120-UNIT CYCLE, so the glow rests dark for 15 units before repeating.", + "The five `ptbtn0Nf` records on the main menu fill their 120 exactly, which is", + "what shows the slack belongs to this record and not to the format.", "", - "GOOD NEWS: the ambiguity this entry used to carry is GONE. It said the cycle", - "might restart at the group's first keyframe (t=6) rather than at 0, giving 123", - "units, and that nothing separated them. Under the corrected layout the group", - "starts at t=0 and ends at t=105, both at alpha 0. There is one reading.", + "Disc-wide over 1781 timed nested records: 92.3% declare exactly their last", + "keyframe time, 7.7% declare more, and 0 DECLARE LESS. That last row is the", + "falsifier -- a cycle cannot restart before its own last pose -- and it never", + "fires.", "", - "🔴 BAD NEWS, AND IT IS NOT PAPERED OVER: 105 units DISAGREES WITH THE", - "MEASUREMENT. The corpus timed the pulse four times at 2.12 / 2.19 / 2.34 /", - "2.31 s. 105 units is 1.750 s at 60 units/s. Scaling by the same factor the", - "ring shows between its declared 120 units and its measured 2.177 s (x1.089)", - "gives 1.906 s -- still about 17% below every measured value. The old 129 gave", - "2.34 s, at the top of the range, which is why it looked right.", + "AND IT SURVIVES THE OBJECTION THIS ENTRY RAISED, using THIS PORT's number.", + "Both candidate periods need the same emulator pacing factor, and the ring", + "measures it independently: declared 120 units -> 2.177 s = 1.0885.", "", - "The port ships the DISC's number and says it is wrong rather than keeping a", - "number that fitted the measurement but was built on a constant that no longer", - "exists. WHAT WOULD RESOLVE IT: whether the group loops from its start at all,", - "or holds at alpha 0 between cycles. Raised with the Decoder 2026-08-29." + " 105 units = 1.750 s nominal, needs a factor of 1.211-1.337 -> EXCLUDES it", + " 120 units = 2.000 s nominal, needs a factor of 1.060-1.170 -> CONTAINS it", + "", + "So 105 cannot reach the corpus's measured 2.12-2.34 s under any pacing the", + "ring also satisfies. At 120 the prediction is 2.177 s. Different elements,", + "different bundles, separate runs, tied only by both declaring 120.", + "", + "HISTORY, because the sequence is what makes this checkable: this entry read", + "129 (last keyframe 105 + the since-deleted exit_ramp_units), then 105 (the", + "group length under the corrected layout, which I shipped knowing it was 17%", + "short of every measurement). The 123-vs-129 pair I once called unseparable", + "STRADDLED the right answer without containing it.", + "", + "The ~3% between 2.177 and the corpus's 2.24 mean is four wall-clock samples of", + "a 2 s period; the Decoder looked for a further declared hold and found none." ] } }, diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 5e7bf857..883d8660 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -4371,3 +4371,53 @@ reason that has evaporated. Verified: the plate is bit-identical 105 units apart (mean diff **0**) and differs at 30 units (0.83). ❔ What would resolve the disagreement: whether the group loops from its start at all, or holds at alpha 0 between cycles. Asked. + +## The plate's period is 120, decoded — and it was falsified with my own ring number + +The Decoder found it in the format: **a nested record is itself a RATC bundle, +and its header's `+0x08` is the loop length** — the same field +`ui_header_time_disc` already tests at the top level. A record's keyframes need +not fill it, and the slack is a hold at the final pose. **`ptbtn00f` is 105 units +of ramp inside a 120-unit cycle**, so the glow rests dark for 15 units. The five +`ptbtn0Nf` records fill their 120 exactly, which is what shows the slack belongs +to *that record* rather than to the format. + +Disc-wide over 1 781 timed nested records: 92.3 % declare exactly their last +keyframe time, 7.7 % declare more, **0 declare less**. That last row is the +falsifier — a cycle cannot restart before its own last pose — and it never fires. + +### The decisive test used this port's number, not theirs + +Both candidates need the same emulator pacing factor, and **the ring measures it +independently**: declared 120 units → 2.177 s → **1.0885**. + +| plate period | nominal | factor needed for the measured 2.12–2.34 s | | +|---|---|---|---| +| 105 units | 1.750 s | 1.211 … 1.337 | 🔴 excludes 1.0885 | +| **120 units** | 2.000 s | 1.060 … 1.170 | ✅ **contains it** | + +**105 cannot reach the measured range under any pacing the ring also satisfies.** +Two different elements in different bundles, measured in separate runs, tied only +by both declaring 120. + +⚠️ **My three readings of this number, in order, are the useful record:** 129 +(`105 + exit_ramp_units`) fitted the measurement for a reason that later +evaporated; 105 (the group length) I shipped *knowing* it was 17 % short; 120 is +decoded. And the 123-vs-129 pair I once called unseparable **straddled the right +answer without containing it** — which is the sharpest argument I have seen +against treating "two candidates, nothing separates them" as if the truth must be +one of the two. + +Verified: bit-identical **120 units** apart (mean diff 0), 0.061 at a quarter and +0.888 at half. Still authored, because the pinned tag does not expose `+0x08` +yet — **delete the entry the day a tag does.** + +### Their `rest()` flag, checked rather than assumed + +They warned that a focus record is exactly the kind of element `rest()` +mishandles, since a pulse's last hold is not its resting state. Censused: **34 +focus-record elements in the export, and only 2 have a varying alpha** — both +`ptbtn00f`, EN and JP. Their `rest.alpha` is **80, identical to their peak**, +which is precisely the pathology described. The port does not hit it because the +plate is drawn through the loop path, and the other **32 are constant-alpha, so +`rest()` is safe for them**. Bounded, not hoped.