re: F6 unit 8 -- the leaf's clock in title units: offset +40, rate ~1/2

The two numbers the port asked for, both from one capture so nothing
crosses runs.

Title rate, which unit 4 flagged as an assumption and is now measured:
ptcopyright declares alpha 0->255 across t=138..160, 22 units, and the
rising run is 22 frames. So 1.0000 title units per frame, with the step
agreeing independently (255/22 = 11.6 against a measured modal 12). That
also confirms the splash's 1 unit/present on a second screen, which it had
never been checked against.

Leaf rate, anchored on the wrap rather than the endpoint: first drawn at
frame 746, wraps at 1914, so 1168 frames for the declared 600-unit loop =
0.5137 units/frame. This SUPERSEDES unit 3's 0.463, which divided 540 units
by 1167 frames -- but the declared track is stationary from t=540 to t=600,
so that endpoint is where motion stops, not where the loop ends.

So: offset +40 title units (confirmed, and the title rate being 1.000 makes
frames and units interchangeable there), rate 0.514x the title's, within 3%
of exactly one half. leaf_t = 0.514 x (title_t - 40).

Flagging rather than smoothing, as they asked: the port runs the leaf
unscaled at 1.0x where this measures 0.514x, so their sweep should cross
twice too fast -- which a viewer ought to notice alongside the early start,
yet the human reports the animation looks correct. Either "looks correct"
is about the effect rather than its speed, or one of the two measurements
is wrong. My rate rests on a single wrap; a longer title capture giving a
wrap-to-wrap period would settle it.

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:06:11 +00:00
parent fd3d936427
commit dfe8e9c1a1

View File

@@ -0,0 +1,70 @@
# F6 unit 8 — the leaf's clock in TITLE units: **offset +40, rate ≈ ½**
**Status: ✅ measured ⟨capture⟩ ×1.** 2026-09-02. The two numbers the port asked
for, both from one capture so nothing crosses runs.
**Question:** what are the leaf's clock origin and rate, expressed in title units?
**Look at:** the title's own rate measured (not assumed), then the leaf against it.
**Not covered:** unit 2's parent-alpha question; `pteff03a`'s absence.
---
## 1 — the title's rate, which unit 4 flagged as an assumption and is now measured
`ptcopyright` declares α `0→255` across `t = 138…160`**22 units**.
```
rising run: 22 frames alphas 11 23 34 46 57 69 81 92 104 115 127 139 …
modal step 12/frame
```
**22 frames for 22 declared units = 1.0000 title units per frame.** The step
agrees independently: `255/22 = 11.6` against a measured modal 12.
✅ This also **confirms the splash's 1 unit/present on a second screen**, which it
had never been checked against.
## 2 — the leaf's rate, anchored on the wrap rather than the endpoint
```
leaf first drawn frame 746
wrap frame 1914 => 1168 frames for the declared 600-unit loop
=> 0.5137 units/frame
```
⚠️ **This supersedes unit 3's 0.463.** That figure divided 540 units by 1167
frames, but the declared track is **stationary from t=540 to t=600** (`540:1521`,
`600:1521`) — so the endpoint I anchored on is where motion *stops*, not where the
loop ends. The wrap is a clean event and gives the honest denominator.
## 🔴 The two numbers
| | |
|---|---|
| **origin offset** | leaf `t=0` at title frame **746**, title starts at **706****+40 title units** (title rate is 1.000, so frames = units) |
| **rate** | **0.514 × the title's rate** — within 3 % of exactly **½** |
`leaf_t = 0.514 × (title_t 40)`
The port's arithmetic was `0.463 × (title_t 40)`. **The offset is confirmed; the
rate is revised upward to ≈ ½**, and ½ is close enough to a round number that I
would treat "the leaf runs at half the title's clock" as the likely intent.
## ⚠️ The disagreement they asked me not to smooth
The port says the human reports **the animation itself looks correct, only starting
early**. But their renderer runs the leaf on the title's clock unscaled — at
**1.0×** where this measures **0.514×**. If that is right, their sweep crosses the
screen **twice too fast**, which a viewer should notice as well as the early start.
**Either the human's "looks correct" is about the effect rather than its speed, or
one of these two measurements is wrong.** I am flagging it rather than resolving
it: my rate rests on a single wrap in a single capture, and a second wrap — a
longer title capture — would settle it by giving a wrap-to-wrap period instead of
a start-to-wrap one.
## Reach
⟨capture⟩ ×1. The title rate has two independent readings within the one capture
(run length and step size). The leaf rate has **one** wrap and is the weaker of the
two numbers.