Found by the independent attacker on DigitalDelay in the Phase 5 trial, 2026-09-29. It applies to every class with a Sync control (DigitalDelay, TapeDelay, AnalogDelay, PingPongDelay, MultiTapDelay).
A class reads the host's transport only when it refreshes, and it refreshes only when a macro is set or a patch changes. There is no per-block hook and no tempo-change hook. So after the host changes tempo, a synced delay keeps playing the old tempo's Time until somebody moves a control.
What a player hears: the song speeds up and the echoes stay where they were, out of time, until a knob is touched.
Also: with Sync on, a Division whose note is longer than the class's longest Time plays the longest Time, not the Division. DigitalDelay's and AnalogDelay's docstrings now say so.
Wanted
- One way for the family to follow the transport: a hook the host calls on a tempo change, or a check at the block rate that costs nothing when the tempo has not moved.
- A test per synced class: change the host tempo with no control move, and the Time follows.
Disclosed in the class docstrings for now.
Found by the independent attacker on DigitalDelay in the Phase 5 trial, 2026-09-29. It applies to every class with a Sync control (DigitalDelay, TapeDelay, AnalogDelay, PingPongDelay, MultiTapDelay).
A class reads the host's transport only when it refreshes, and it refreshes only when a macro is set or a patch changes. There is no per-block hook and no tempo-change hook. So after the host changes tempo, a synced delay keeps playing the old tempo's Time until somebody moves a control.
What a player hears: the song speeds up and the echoes stay where they were, out of time, until a knob is touched.
Also: with Sync on, a Division whose note is longer than the class's longest Time plays the longest Time, not the Division. DigitalDelay's and AnalogDelay's docstrings now say so.
Wanted
Disclosed in the class docstrings for now.