fix: carry a dotted note's dots into a guessed tuplet-normal - #458
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human Summary
A bug with automatic tuplet note duration detection, both found and fixed by AI.
Summary
When a
<tuplet>says nothing about its normal side,TupletReader::guessNormalFromNotereconstructs that side from the note's
<time-modification>. If the<time-modification>names anormal-type, the duration and dots come from thenormal-type/normal-dotgroup. When it doesnot, the reader already took the duration from the note's own
<type>but leftnormalDotsunspecified.
Per the schema, an absent
normal-typemeans the normal notes are the note's own written figure,dots included, so a dotted note in such a tuplet read as an undotted normal figure and was written
back as a
<tuplet-normal>with no<tuplet-dot/>.The fallback now takes the dot count from the note's own
<dot>elements, the way the actual sidealready does (the same fix as #449, on the other side of the ratio). A note with no dots now guesses
zero dots rather than the unspecified sentinel, so a second round trip reads the same value. An
explicit
normal-typegroup still wins. Nothing about the api's shape or vocabulary changes; onlywhat the reader records, so this is non-breaking.
Testing
cases fail with
normalDotsreported as -1make fmtandmake fmt-checkpassmake api-test: all tests pass (5898 assertions in 662 test cases)make api-roundtrip: 414 passed, 0 failed (of 414 pinned)make api-roundtrip-discover: 414 PASS, 426 FAIL; no file unlocked by this change, sonothing was added to the baseline
make test-all: core round trip passes (841 test cases), core unit passes (603 assertions in69 test cases), plus the api suites above
The tests added are a single-dot case, a double-dotted case proving the count rather than the
presence of one dot, a guard that an explicit
normal-type/normal-dotgroup is not overwritten, azero-dot case, and an end-to-end test that reads a dotted note in a
normal-type-less tuplet,writes it, and checks the written
<tuplet-normal>carries a<tuplet-dot/>.References
tuplet-normaldrops the note's dots #452TupletReader#440, fix: guess each tuplet side from its own data #449