re: F6 unit 9 -- sweep period and onset, as ratios reproduced across two runs

Two captures of the same animation disagree on frame counts by 1.947x, so
frames are not comparable across runs. Expressed as ratios to a long
in-capture baseline, both runs agree: loop period = 13.93 baselines (0.35%
apart), and the sweep starts 0.79-0.80 baselines BEFORE the plate (0.9%).

This answers F6: the sweep does not start at t=0 as the port has it, nor
exactly with the plate -- it leads the plate by about 40 title units, under
a second, which is consistent with what the human reported seeing.

Surfaces a conflict rather than smoothing it: unit 8's title rate of 1.0
units/frame (from ptcopyright) and the plate's 0.571 units/frame are 1.75x
apart in the SAME capture. Either an element's declared ramp is misread or
the two are not on one clock -- the port's clock:"shared" premise. The
ratios stand without a clock; the title-unit conversions are 🟡 pending F4.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-02 19:20:30 +00:00
parent e78420a774
commit c614f908e0
2 changed files with 82 additions and 4 deletions

View File

@@ -0,0 +1,76 @@
# F6 unit 9 — the sweep's loop period, and when it starts
**Question (one sentence):** does the title's sweeping glow start when the plate
appears, and how long is one pass?
**What the human looks at:** boot the title, watch the white sweep. Pass = it
first enters the screen shortly *before* the "PRESS Ⓐ" plate fades in — under a
second before, not at the very start of the title.
**What this does NOT cover:** which declared keyframe drives the sweep, whether
the artwork and the plate share one clock (that is F4), and F5 entirely.
**Instrument:** ⟨capture⟩ — two independent Canary runs, `f6` and `f6b`.
## ⚠️ First, the thing that invalidates frame counts across captures
The same animation took **1168 frames** in one run and **600** in the other —
**1.947×** apart. Every other interval in those captures scales by the same
factor (the baseline below: **1.953×**). So the runs differ in present rate by
~1.95×, and **any timing quoted in captured frames is specific to its run.**
This is why the numbers below are all ratios. It also means a frames-based rate
carried from one capture to another is wrong by up to 2×.
## Measured (phase-free, reproduced across both runs)
Baseline interval = from the `x=-0.740` element appearing to the plate
appearing. Chosen because it is long; a short alpha ramp quantises to ±1 frame
and gave an 8% spread where this gives 0.35%.
| | f6 | f6b | agreement |
|---|---|---|---|
| sweep loop period | 1168 fr | 600 fr | — (not comparable) |
| baseline | 84 fr | 43 fr | — |
| **period / baseline** | **13.905** | **13.953** | **0.35%** |
| **sweep starts before plate** | **0.798** | **0.791** | **0.9%** |
The cycle boundary is unambiguous: the sweep enters at `x=-1.540` and wraps from
`x=+1.840` back to `x=-1.540`, so first-appearance→wrap is one whole period.
Calibrating the baseline with the plate's declared 12-unit ramp (238→250) puts
it at ~4852 title units, so in title units: **period ≈ 670720**, **the sweep
leads the plate by ≈ 40**.
## What this says about F6
**The sweep does not start at title `t=0`, and it does not start exactly with the
plate.** It starts a short, reproducible interval *before* the plate — ~0.8 of
the baseline, ≈40 title units, well under a second.
So the human's report is approximately right and the port's behaviour is not: at
`t=0` the port starts it roughly 200 units early. The human could not have seen a
40-unit lead as separate from the plate, and did not claim to.
## 🟡 A conflict I did not smooth
Unit 8 measured the title clock at **1.0000 units/frame** in `f6` from
`ptcopyright`'s 22-unit ramp taking 22 frames. In the *same capture*, the plate's
declared 12-unit ramp takes 21 frames — **0.571 units/frame**, 1.75× apart.
One of three things is true: `ptcopyright`'s ramp is not 22 units, the plate's is
not 12, or **the two elements are not on one clock** — which is exactly the
premise (`clock: "shared"`) the port's `flow.json` is built on. Not resolved
here; it needs F4.
Because of this, the title-unit conversions above are 🟡. The **ratios are ✅**
they need no clock at all.
## Not settled
* Still **one wrap per capture**, so the period is start→wrap, not wrap→wrap. It
is a full cycle by the x-boundary argument, but a second wrap would be better.
The title exits before one arrives; `f6b` ran 504 frames past the wrap and the
next was ~100 short.
* Which declared keyframe the sweep's leaf hangs off.
* F5, untouched.

View File

@@ -25,19 +25,21 @@ win="$(xdotool search --name "Xenia-canary" | tail -1)"
xdotool windowactivate "$win" 2>/dev/null; xdotool key --window "$win" F10; xdotool key F10
echo "armed at ${SECONDS}s"
sleep 12; pad "press=A"; sleep 0.4; pad ""; echo "A (skip video) at ${SECONDS}s"
# ⚠️ ARMING IS NOT CONFIRMED BY SENDING THE KEY. Twice now a probe has printed
# "armed", pressed on, and written no draw log at all -- once because the window
# lookup failed, once with the window found and the key sent. A probe that cannot
# confirm its own instrument is recording is a probe whose negatives mean nothing.
# So: wait for the log to exist AND grow, and abort loudly if it does not.
for _ in $(seq 1 20); do
for _ in $(seq 1 45); do
sz=$(stat -c %s "$OUT"/xenia_re_ui_draws_*.log 2>/dev/null | head -1 || echo 0)
[ "${sz:-0}" -gt 0 ] && break
sleep 1
done
[ "${sz:-0}" -gt 0 ] || { echo "FATAL: armed but no draw log after 20s -- not recording"; pkill -x xenia_canary; exit 1; }
[ "${sz:-0}" -gt 0 ] || { echo "FATAL: armed but no draw log after 45s -- not recording"; pkill -x xenia_canary; exit 1; }
echo "logging confirmed at ${SECONDS}s (${sz} bytes)"
sleep 12; pad "press=A"; sleep 0.4; pad ""; echo "A (skip video) at ${SECONDS}s"
sleep 150 # let the title build in and settle, no further input
sleep 260 # long enough for TWO leaf wraps, not one
pkill -x xenia_canary
echo "done at ${SECONDS}s"; ls -la "$OUT"/*.log 2>/dev/null