Files
Sylpheed/docs/re/f6-unit10-parent-alpha-gates-the-sweep.md

4.0 KiB
Raw Permalink Blame History

F6 unit 10 — what makes the sweep start, and when

Question: why is the sweep hidden for the first part of the title, and what turns it on?

What the human looks at: the sweep should be absent at the very start, fade up once the title art is established, and then keep looping. Pass = it fades in partway through the build-in. Fail = present from frame one, or popping in.

What this does NOT cover: F5, the plate's identity, and the loop period.

Instruments: ⟨disc⟩ for the declarations, ⟨capture⟩ for the two runs.

Decoded — the gate is the PARENT's alpha, and it is declared

GP_TITLE build 4 (and 7) declare both hosts with a five-key ramp:

ptloop01.rat / ptloop02.rat   t=0 α0 · t=70 α0 · t=100 α255 · t=238 α255 · t=250 α0

Alpha 0 until t=70, up to full by t=100, and 238…250 is an EXIT ramp. That answers the brief's open question directly: for these elements 238…250 starts nothing, it ends them.

⚠️ Build matters. Builds 5 and 6 declare the same two records as a single keyframe at flat α255 — no ramp at all. So "what does ptloop01 do" has no answer until the build is named, and the one the human is watching is 4/7.

Measured — the parent's alpha is multiplied into the leaf's

The leaf pteff03 declares α 255 falling to 128 across its own t=0…150. The capture shows the sweep rising 8→255 in that same window, so the leaf alone predicts the wrong direction — the control could have flattered the hypothesis and did not.

Decomposing observed = parent × leaf / 255 using the leaf's declared curve, the implied parent ramps up and then pins at ~254 and holds across hundreds of frames while the observed alpha swings 242 → 132 → 145.

🔴 Numbers corrected by reverify-pulse-and-decomposition.md. This page first said 254.0256.9 and 253.9254.9; those were the sampled rows I printed, not the series. First-cycle truth: 250.9260.5 (f6, n=1128) and 253.1255.0 (f6b, n=560). The conclusion is unchanged and restricted to the first cycle. Over that whole swing the leaf's declared curve predicts the drawn alpha to within one alpha level.

A flat 255.0 residual across a large excursion is the part that could have failed. It settles the standing 🟡 on whether parent alpha is multiplied in: it is.

Leaf runs at half the title's clock — and this restores a number I withdrew

Using the parent's declared 30-unit ramp (t=70…100) as an in-capture title clock, and the leaf's declared 600-unit loop as the leaf clock:

title clock leaf clock leaf / title
f6 1.0714 u/fr 0.5137 u/fr 0.4795
f6b 2.1429 u/fr 1.0000 u/fr 0.4667

2.7% apart, ≈ ½. The two runs differ 2× in frames and agree on the ratio.

🔴 I over-withdrew unit 8's 0.514 last iteration. Frames-based rates were the thing that failed, and I threw the ratio out with them. The ratio was right: leaf ≈ 0.5 × title now has two independent runs and a declared calibration behind it. The port should reinstate it, not drop it.

What this says about F6

The sweep is switched on by its parent at t=70, full at t=100 — not at t=0, and not by anything to do with the plate. It never plays its 238…250 exit because the title clock freezes inside [160,236] (ui-clock-freezes-at-settle.md), which is why it loops indefinitely on a held title.

Not settled

  • 🟡 The element I have been calling "the plate" is unidentified — it is tracked by screen position only. The declared plate is at t≈236; in-capture it lands at t≈137 on this title clock. Until it is named, that 1.7× stays unexplained and no plate-relative number should be trusted. Unit 9's onset fraction is measured against it, so it inherits this.
  • pteff03a (ptloop02's leaf) is still absent from every capture.
  • Wrap-to-wrap period; F5, untouched.