From f3f31d492350a1766901b064b2fc602354712425 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sat, 29 Aug 2026 19:42:28 +0000 Subject: [PATCH] port: the plate's period is 120, decoded -- and 105 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. A record's keyframes need not fill it and the slack is a hold at the final pose, so ptbtn00f is 105 units of ramp inside a 120-unit cycle -- the glow rests dark for 15 units. The five ptbtn0Nf records fill their 120 exactly, which shows the slack belongs to that record and not to the format. Disc-wide over 1781 timed nested records: 92.3% declare exactly their last keyframe time, 7.7% more, 0 LESS -- the falsifier never fires. THE DECISIVE TEST USED THIS PORT'S NUMBER. Both candidates need the same emulator pacing factor, and the ring measures it independently: declared 120 -> 2.177 s -> 1.0885. 105 units needs 1.211-1.337 to reach the measured 2.12-2.34 s, which EXCLUDES it; 120 units needs 1.060-1.170, which CONTAINS it. Two different elements in different bundles, separate runs, tied only by both declaring 120. My three readings in order are the useful record: 129 (105 + the since-deleted exit_ramp_units) fitted the measurement for a reason that 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 -- 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 0), 0.061 at a quarter, 0.888 at half. Still authored because the pinned tag does not expose +0x08; delete the entry the day a tag does. THEIR rest() FLAG, CHECKED RATHER THAN ASSUMED: they warned a focus record is the kind of element rest() mishandles. Censused -- 34 focus-record elements, only 2 with a varying alpha, both ptbtn00f, whose rest.alpha of 80 IS their peak, exactly the pathology described. The port does not hit it because the plate draws through the loop path, and the other 32 are constant-alpha so rest() is safe. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- authored/timing.json | 55 +++++++++++++++++++++++++----------------- docs/port/DECISIONS.md | 50 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 83 insertions(+), 22 deletions(-) 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.