Fix ugly MusicXML durations & offsets #1632
Merged
Conversation
This file contains 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
TimFelixBeyer
changed the title
|
this looks good -- can you rename "PP" in the tests to "pp" -- capital letters should only be used to represent classes, not instances of classes. Then anyone w/ merge rights should feel free to merge. |
|
I actually fully agree, just did this to be in-line with all the other tests. |
mscuthbert
approved these changes
Oct 4, 2023
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.
We all know the ugly offsets (3875/480, 161/180, etc.) that happen after importing some musicXML files.
This usually occurs because the file contains tuplets with strange durations that cannot be represented exactly using integer
<duration>tags in musicXML. For this reason, rounding errors can accumulate and lead to over/underfull measures.Currently, if a measure is overfull, music21 just accepts that as a fact and increases the duration of the measure, shifting all following objects and resulting in them having very odd offsets.
This proposal deals with this by automatically detecting such cases, warning the user, and fixing them.
The change only affects behavior if the measure duration resulting from the contained notes differs from the duration dictated by the time signature by less than 0.5 and is a very ugly duration.
In my testing, this fixes the vast majority of imports without breaking anything else.
Let me know what you think!