A teammate’s pull request adds grace notes, and with them two conveniences. Visitors get a default for the grace-note method, so the next new kind won’t break every visitor’s build. And the status bar under the score, which warns about notes out of the singer’s range after every edit, keeps one RangeCheck instead of making a new one each time. QA reports that the status bar lists the same note again and again as an arranger edits, and that a grace note far above the altos’ range is never flagged.
Arrangers stop trusting the status bar, and an unsingable ornament reaches rehearsal.
Reproduce
bar = new StatusBar(55, 79), then bar.refresh(score) twice, with score[grace g1 84, note n1 50 (1)]. Both refreshes should say “flagged: g1, n1”. Today the first says “flagged: n1” and the second “flagged: n1, n1”.
Acceptance criteria
- A grace note outside the range is flagged by its id, once, like a note; a grace note adds no beats to the playing time.
- Every refresh reports the score as it is now: refreshing twice, or after an edit, never carries a previous refresh’s flags.
- Chords, repeats, rests and kinds the check has never seen behave as before.
- Each operation decides what a grace note means for it in its own code.
Notes
- Each case makes one status bar, refreshes it, then refreshes it again (one case after an edit, a different score), and prints the two results joined by “ || ”. Some cases then add “ | beats: N”, the last score’s playing time from totalBeats (Go: TotalBeats; Rust: total_beats).
- Keep the names and signatures of Note, Rest, Section, Chord, Grace, PlayingTime, RangeCheck, totalBeats, outOfRange, StatusBar and its refresh (Go: TotalBeats, OutOfRange, NewStatusBar, Refresh; Rust: total_beats, out_of_range, StatusBar::new, refresh). You may change the Visitor contract.