From 615817d70e19d840a27c622732ddf05b5276798d Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 11:22:59 +0000 Subject: [PATCH] handoff: the fade ramp is 10 units decoded, and screen info was stale Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/port/HANDOFF.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 1512ec48..f2d4e1dd 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -2533,6 +2533,42 @@ whatever it returns — the same reason a truncated log and a t=0 render both lo fine from inside. Template matching against the exported cue with a bed-only control has no such knob, which is the right fix rather than a better threshold. +## 🔴 2026-08-30 — your fade ask: the ramp IS 10 units, and my `screen info` was STALE + +**Your number survives my attempt to refute it.** `pteff00.prm`'s final ramp on +build 5 is **70 → 80 = 10 units ≈ 0.167 s**. The `~24 units` HANDOFF told you to +author is wrong. + +🔴 **And the reason it stood so long is a tooling trap you should know about.** The +`sylpheed-cli` in this container was built **2026-08-29 12:38**, *before* the +keyframe-record-layout fix. The old parser shifted every time by one slot and could +not time a group's final pose: + +``` +stale pteff00.prm 4 kf rest t=70 [12:0,0 70:0,0 80:0,0 -:0,0] +fresh pteff00.prm 4 kf rest t=12 [ 0:0,0 12:0,0 70:0,0 80:0,0] +``` + +Both are well-formed; neither announces its age. `screen-transitions.md` argued from +*"there is exactly one untimed keyframe"* — **the stale parser's artefact**. That +premise is now marked refuted in place. + +⚠️ **`cargo build -p sylpheed-cli` before trusting `screen info`.** ✅ Renders are +**byte-identical** across the two binaries (max per-channel difference **0**), so +`screen render` and anything from element identity, pivots or keyframe *counts* is +unaffected — it is the **times** that move. + +### Your actual question, as far as I can take it + +✅ **The ~0.4 s is NOT the ramp alone.** 0.4 s is ~24 units against a decoded 10, so +~14 units belong to something else. That much is decoded-vs-measured and does not +depend on any decomposition. + +🟡 **That the remainder is exactly the black hold is arithmetic that fits, not a +measurement** — 14 units = 0.233 s, inside this corpus's own 0.17–0.23 s plateau. +You named this risk yourself and you were right to. **Author nothing from the +composition.** What you can take is the decoded 10. + ## ✅ 2026-08-30 — `on_cancel` from the MAIN MENU is measured: it goes to the TITLE You flagged `on_cancel` as still authored. Half of it is now measured — the half