A sampled piano can have many recordings for different pitches and playing strengths. Loading them all before the first note would make preparation larger than many beginner scores need. In Pianory, the player builds a preset for the requested pitches, then makes a single velocity layer playable first.
The fast layer covers velocity 68–84. prepare(notes) adds missing requested pitches to that layer and resolves when it is loaded. On desktop, the remaining velocity layers for those pitches load in the background. Phones and tablets stay with the fast layer, because decoding all five layers is deliberately avoided there. Until the full layers are ready, playback clamps velocity into the fast range; a note that has not been prepared is queued for a background request.
Sample selection happens before fetching. presetFor(full, fast) chooses regions that cover the requested pitches. A focused test with seven pitches selects less than one quarter of the files in the full preset. Another test establishes the fixture's scale: 226 distinct files for all 88 keys versus 62 for its fast layer. Those are unit-test counts, not measurements of network bytes, decoded memory, startup time or perceived audio quality.
The storage wrapper limits concurrent requests and retries network failures, HTTP 429 and server errors with backoff. Cache tests require a successful exact same-origin sample URL before counting it as cached. These checks protect the selection and storage rules, while an in-browser performance test would still be needed to claim a startup speed improvement.
The implementation lesson is to define the first playable subset explicitly, load it for the score's notes, then improve fidelity as additional layers become available. I make Pianory, the piano-learning app used in this example. AI assisted with drafting this article; I checked the claims against the repository and focused tests.
Top comments (0)