I build Pianory, a browser-based piano learning app. AI helped draft this article; I checked the claims against src/lib/domain/course-timeline.ts and its focused test suite.
A score import needs a stable representation of musical time. In Pianory's course timeline domain contract, beat positions and durations are rational quarter-note values, rather than floating-point estimates. The fraction helper requires a reduced numerator and denominator, so equivalent values have one canonical form.
Comparison uses BigInt cross-products. That matters when numerator times denominator exceeds JavaScript's safe-integer range: rounding could make two distinct beat positions appear equal or reverse their order. The focused tests include such a large-integer comparison and reject noncanonical fractions.
Pickup measures create a second edge case. An opening partial measure does not mean every later bar may be partial. The validator accepts a final partial bar when it exactly complements the opening pickup in the same meter. It rejects duration combinations that do not satisfy that relationship. That is a domain rule for a score timeline, not a claim that every imported MIDI file has perfect notation.
The design lesson is to make the time unit and equality rule explicit before wiring import or playback adapters. A versioned JSON score contract with canonical fractions gives tests a precise target. pnpm exec vitest run src/lib/domain/course-timeline.spec.ts passed 8 tests on 29 October 2026. This focused check verifies the domain model and tests only; I did not trace every production import or playback path for this article.
Relevant source: src/lib/domain/course-timeline.ts and src/lib/domain/course-timeline.spec.ts.
Top comments (0)