fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

handoff: the fade ramp is 10 units decoded, and screen info was stale

Browse Source 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 11:22:59 +00:00
parent 53997dfcbd
commit 615817d70e
1 changed files with 36 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/port/HANDOFF.md
View File

@@ -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