Repository navigation
MusicXML import: ignore sound elements without a tempo - #2570
Merged
Merged
Conversation
MeasureBPM returned the tempo of the first <sound> in a measure's directions, even when that <sound> had no tempo attribute. MuseScore writes <sound dynamics="..."/> for every dynamic marking, so each measure with a dynamic got a 0 bpm tempo marker, and a real tempo change written after a dynamic in the same measure was dropped.
emeraldsingers
added a commit
to emeraldsingers/UtauV
that referenced
this pull request
Oct 30, 2026
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.
MusicXML.MeasureBPMreturns the tempo of the first<sound>it finds in a measure's directions, whether or not that<sound>has atempoattribute. MuseScore writes<sound dynamics="..."/>for every dynamic marking, so:The
TimeAxisguard against zero bpm now stops these markers from producing NaN times, but they stay in the project's tempo list and the real tempo changes are still lost. This may be where the zero/NaN tempo in #2391 came from (MusicXML exported from MuseScore 4). I could not check that, because the reporter's file isn't attached.Change: only use a
<sound>whosetempoattribute is set and greater than 0. The MusicXML spec says a tempo of 0 means "prompt the user", so it is not a usable tempo either.Test:
MusicXMLTest.SoundWithoutTempoTestloads a small new fixture,sound-dynamics-without-tempo.musicxml. It has 100 bpm in measure 1, dynamics-only<sound>elements in measures 1 to 3, and a dynamic followed by 80 bpm in measure 3. Expected tempos:100@0, 80@3840. Before the change they were100@0, 0@1920, 0@3840. The fixture was written by hand, which is noted inFiles/MusicXML/README.mdbecause the other files there come from the MusicXML test suite.Ran
dotnet run --project OpenUtau.Test/OpenUtau.Test.csprojon macOS (arm64, .NET 10.0.12), rebased on b7c35b9: 709 total, 701 passed, 5 failed, 3 skipped. The 5 failures are timing tests (RenderViewTestx4,WaveformRefreshTest.CoalescesBurstsAndPostsPromptly) that time out the same way on unmodified master b7c35b9 in this environment, so they are not caused by this change. The 3 skips are live tests that needOPENUTAU_TEST_SINGERS,ENUNU_TEST_VOICEorOPENUTAU_BRIDGE_DISCOVERY.OpenUtau.UiTestwas not run, and the change was not tried in the app UI.