From 06aa031980a2336918b883238eea8a2150f01c57 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 19:13:23 +0000 Subject: [PATCH] re: a ninth transition -- the same origin gives gap 0 and 1 by destination sylpheed-port confirmed "nothing declared predicts the gap" from their export independently, and deliberately declined to search combinations: four pairs against many candidate two-screen functions fits by construction. Right call, and it applies to me unchanged. So this iteration adds a PAIR rather than a fit. menu -> a second screen outside GP_TITLE, reached by stepping the cursor two items before arming. The button is not controlled -- there is no focus readout -- so the destination is identified afterwards by its draw signature: incoming primitive [255] at 7-9 draws/frame, against the first run's [127] at 12-13. Different screens. Outgoing quad rises 25, 51, 102, 229, 255 across frames 37-42, then at frame 44 the new screen is already drawing. NO empty frame anywhere. GAP = 0. So the menu as origin gives four values across four destinations: title 0, EXTRAS 1, other-1 1, other-2 0. The same origin yields both 0 and 1 depending on where it goes, while the two repeated pairs stay internally identical (3,3,3 and 2,2). Further evidence for the ordered pair over the origin. Recorded as an observation with its counter-example rather than fitted: the incoming screen's own full-screen primitive is [255] where the gap is 0 and [127] where it is 1, which suggests a screen beginning from opaque black needs no blank frame. That FAILS on menu -> EXTRAS, which declares a black backdrop and still gives 1. Nine transitions against many candidate functions is the construction the port declined to search, and I am not searching it either. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/data/fade-four-transitions.txt | 40 ++++++++++++++++++++++++++ tools/re-capture/fade_decompose.sh | 12 ++++++++ 2 files changed, 52 insertions(+) diff --git a/docs/re/data/fade-four-transitions.txt b/docs/re/data/fade-four-transitions.txt index e2c3ff82..fdd58ee3 100644 --- a/docs/re/data/fade-four-transitions.txt +++ b/docs/re/data/fade-four-transitions.txt @@ -283,3 +283,43 @@ frame untextured full-screen textured (distinct) draws tex # determines it, reproducibly. Still nothing declared predicts which value a pair # gets, so this remains a description with five replicates behind it rather than a # rule. + +################################################################################ +# NINTH TRANSITION: menu -> a SECOND screen outside GP_TITLE, via (A). 2026-08-30. +# +# Taken because the ordered-pair claim needs a second distinct destination from +# the SAME origin -- data, not a fit. sylpheed-port checked "nothing declared +# predicts the gap" independently and confirmed it, and DECLINED to search +# combinations on the grounds that four pairs against many candidate two-screen +# functions fits by construction. This adds a pair instead. +# +# ⚠️ The button is not controlled -- there is no focus readout -- so the +# destination is IDENTIFIED AFTERWARDS by its draw signature: +# menu -> other (1st): incoming primitive [127], 12-13 draws/frame +# menu -> other (2nd): incoming primitive [255], 7-9 draws/frame +# Different screens. +# +# frames 21-34 menu settled ([64]); textured content fades 32-34 +# frames 37-42 outgoing quad 25, 51, 102, 229, 255 +# frame 44 the new screen is ALREADY drawing -- [255] plus textured +# content. NO empty frame anywhere. +# +# ✅ GAP = 0. +# +################################################################################ +# NINE TRANSITIONS. The menu as origin now gives FOUR values across FOUR +# destinations: title 0, EXTRAS 1, other-1 1, other-2 0. +# +# 📌 That is further evidence for the ordered pair over the origin: the same +# origin gives both 0 and 1 depending on where it goes, and the two repeated pairs +# remain internally identical (3,3,3 and 2,2). +# +# 🟡 AN OBSERVATION, EXPLICITLY NOT A RULE. The incoming screen's own full-screen +# primitive differs between the two "other" destinations: [255] where the gap is 0, +# [127] where it is 1. A screen that begins from opaque black would not need a +# blank frame, since its own backdrop covers it -- which is a tempting mechanism +# and it FAILS on menu -> EXTRAS: EXTRAS declares a black backdrop +# (ui-forced-backdrop.md, 12 of 16) and still gives 1. +# 🔴 So it is recorded as an observation with its counter-example, not fitted. Nine +# transitions against many candidate two-screen functions is the same construction +# sylpheed-port declined to search, and their reason applies unchanged to me. diff --git a/tools/re-capture/fade_decompose.sh b/tools/re-capture/fade_decompose.sh index 9347c633..063d2760 100755 --- a/tools/re-capture/fade_decompose.sh +++ b/tools/re-capture/fade_decompose.sh @@ -98,6 +98,18 @@ elif [ "$WHERE" = "menu2other" ]; then python3 "$SD/pad.py" tap B 0.5; sleep 6 case "$w" in extras*) echo " focus was EXTRAS — stepping once" python3 "$SD/pad.py" dpad UP 0.3; sleep 2;; esac + # STEPS=n moves the cursor n further items before arming, so a second run can + # leave the menu by a DIFFERENT button. The menu has four non-EXTRAS exits, and + # a second distinct destination from the same origin is what separates + # "the gap is per ordered pair" from "the gap is per origin plus destination + # class". ⚠️ There is no focus readout, so which button this lands on is not + # controlled -- it is IDENTIFIED afterwards by the destination's draw + # signature, and if the signature matches the previous run it is the same pair + # and the run says nothing new. + for _ in $(seq 1 "${STEPS:-0}"); do + echo " STEPS: moving the cursor one item" + python3 "$SD/pad.py" dpad DOWN 0.3; sleep 2 + done shot "$OUT/armed-on-menu.png" echo " arming on: $(python3 "$SD/which_title_screen.py" "$OUT/armed-on-menu.png")" BTN=A