I make Pianory. AI helped draft this article; I checked the code paths and focused tests described here against the repository.
A player can stop its UI at the end of a finite loop while a long note or a scheduled metronome click still extends past the passage boundary. That makes the loop boundary a scheduling rule, not just a transport-state rule.
Pianory's score player computes the end quarter for a passage. For a finite loop, it caps each scheduled note's end quarter at that passage end and caps its audio duration to the remaining time. The metronome path likewise caps clicks at the boundary. When the configured repetition budget is spent, the scheduler does not append another passage anchor and finishes playback.
A focused deterministic test uses a short one-pass loop with metronome enabled. It checks that one note is scheduled, that the note ends within the passage boundary, that every click stops within it, and that the player reaches stopped status. Other tests cover one and two passes, preserving a tempo map across a full-score repeat, and changing a live loop without replaying the next onset.
The useful contract is that a finite passage limits every scheduled sound-producing event, even if an event would naturally last longer. The tests use a fake audio rig and check scheduler outputs. They do not establish how a physical audio device sounds or prove browser playback under every timing condition.
Source: src/lib/sheet/player.ts and src/lib/sheet/player.spec.ts in the Pianory repository.
