MuseScore
MuseScore copied to clipboard
musescore
[MU4 Issue] Ties Over the Barline Crash Musescore
After the new Musescore update, trying to add ties over the barline crashes the program (also corrupted my score).
For example, trying to add a tie from a 16th-note at the end of one measure to an 8th-note at the beginning of the next measure causes the program to freeze and crash.
Hadn't had this issue occur before this morning when I downloaded the new update, I'm working on a percussion ensemble score for my University. Ties used to function normally.
For context, I'm using Musescore 4 on a Windows laptop.
Any help on this issue would be great, I tried to go back to the original Musescore 4 build that I was using but I'm having trouble figuring that out at the moment.
Could you upload a score here where this happens (.zip it first)? I can't reproduce this myself at a first try (on Windows or Linux) but obviously it sounds serious.
Transmissions.zip Issue is between measures 48-49 in the vibraphone, I've put the notes that need to be tied over the bar. I had everything worked out before this update, after I opened the score from updating there were a lot of notes suddenly missing, this was one of those areas. Mostly notes landing on beat 1 of a measure in random areas/instruments suddenly disappeared. In some cases, I had to completely delete entire measures of notes to then replace what had been lost because of the program being fussy.
This is a MusicXML file and I get an error saying it's corrupted when opening; so this crash may be related to that, and I'll need to leave it to cleverer people to investigate.
The error doesn't give any details (yet) about what is corrupted but a build of https://github.com/musescore/MuseScore/pull/15488/ does:
Incomplete measure: Measure 35, Staff 1. Found: 30/16. Expected: 4/4. Incomplete measure: Measure 35, Staff 12. Found: 14/8. Expected: 4/4. Incomplete measure: Measure 39, Staff 1. Found: 30/16. Expected: 4/4. Incomplete measure: Measure 39, Staff 2. Found: 30/16. Expected: 4/4. Incomplete measure: Measure 41, Staff 1. Found: 62/16. Expected: 8/4. Incomplete measure: Measure 41, Staff 2. Found: 62/16. Expected: 8/4. Incomplete measure: Measure 43, Staff 2. Found: 29/16. Expected: 4/4. Incomplete measure: Measure 43, Staff 3. Found: 29/16. Expected: 4/4. Incomplete measure: Measure 43, Staff 6. Found: 14/8. Expected: 4/4. Incomplete measure: Measure 43, Staff 7. Found: 14/8. Expected: 4/4. Incomplete measure: Measure 43, Staff 8. Found: 14/8. Expected: 4/4. Incomplete measure: Measure 45, Staff 8. Found: 14/8. Expected: 4/4. Incomplete measure: Measure 47, Staff 2. Found: 29/16. Expected: 4/4. Incomplete measure: Measure 47, Staff 3. Found: 29/16. Expected: 4/4. Incomplete measure: Measure 47, Staff 6. Found: 14/8. Expected: 4/4. Incomplete measure: Measure 47, Staff 7. Found: 14/8. Expected: 4/4. Incomplete measure: Measure 81, Staff 7. Found: 20/4. Expected: 12/4. Incomplete measure: Measure 83, Staff 7. Found: 7/4. Expected: 4/4.
So the crash may be because of this corruption (which may be because of a problem with the MusicXML import). This is good, in the sense that it's likely not a general problem, but obviously not good for your particular situation. That said, even with this file I can't reproduce the problem myself; I can add the tie from b48-49 just fine.
This tie problem may be related to one of the issues mentioned by @cbjeukendrup here: https://github.com/musescore/MuseScore/issues/15878#issuecomment-1382878952
I see the same as Simon: the score is reported as corrupted (and indeed, the mentioned measures do look weird), but still I can apply the tie without a crash.
One more observation: when I open this mxl file in Dorico, Dorico opens it without complaining and it seems okay; at least, no overfilled measures, and it looks like this:
@JTH2001 Is that correct? In that case, it might be an issue with MuseScore's MusicXML import code. Or Dorico just silently fixes the corruptions, or it just uses different properties from the MusicXML file to determine the note durations so that it isn't affected by the corrupted durations.
In any case it would be useful if you could also upload the file as a MuseScore file, rather than converted to MusicXML.
I guess that's the real issue then, my file is corrupted in Musescore itself and has been since I updated the program. I didn't have any corruption problems until I opened the score up following the update today. I mentioned that a little in my original post but I didn't emphasize it like I should have. I don't really know how to fix this issue or how to go about repairing it, but I've tried going back and "resetting" the measures that are causing problems.
The question is, would this continue to be a corruption issue even if I go back and fix the measures that are screwed up?
It's very unlikely that the corruption is caused by the update; it has probably happened the last time that you saved it before the update (but of course you can't have noticed that, because there is no warning before saving a corrupted score).
If you fix the measures containing the corruptions, then they should not come back. If you want, you can also upload the .msxz file here, so that I can try to fix the corruptions for you.
The corruption is in the MusicXML file, it is not caused by the importer (which literally imports what is in the file, this could be improved upon). Measures 35 contain issues in parts 1 and 10, where all notes are in voice one, but backups results in overlapping notes. This is not expected by MuseScore and probably messes up the corruption calculation.
Contents of these two measures: part P1 measure 35 0.00000 voice 1 quarter rest duration 12 (0.25000) 0.25000 backup 9 (0.18750) 0.06250 voice 1 16th C4 duration 3 (0.06250) 0.12500 voice 1 16th D4 duration 3 (0.06250) 0.18750 voice 1 16th E4 duration 3 (0.06250) 0.25000 voice 1 dotted half rest duration 36 (0.75000) 1.00000 backup 33 (0.68750) 0.31250 voice 1 16th F3 duration 3 (0.06250) 0.37500 voice 1 16th A3 duration 3 (0.06250) 0.43750 voice 1 16th B3 duration 3 (0.06250) 0.50000 voice 1 16th C4 duration 3 (0.06250) 0.56250 voice 1 16th F3 duration 3 (0.06250) 0.62500 voice 1 16th G3 duration 3 (0.06250) 0.68750 voice 1 16th E3 duration 3 (0.06250) 0.75000 voice 1 16th D3 duration 3 (0.06250) 0.81250 voice 1 16th E3 duration 3 (0.06250) 0.87500 voice 1 16th F3 duration 3 (0.06250) 0.93750 voice 1 16th G3 duration 3 (0.06250)
part P10 measure 35 0.00000 voice 1 quarter rest duration 12 (0.25000) 0.25000 backup 6 (0.12500) 0.12500 voice 1 eighth C4 duration 6 (0.12500) 0.25000 voice 1 dotted half rest duration 36 (0.75000) 1.00000 backup 30 (0.62500) 0.37500 voice 1 eighth rest duration 6 (0.12500) 0.50000 voice 1 quarter C4 duration 12 (0.25000) 0.75000 voice 1 eighth C4 duration 6 (0.12500) 0.87500 voice 1 eighth C4 duration 6 (0.12500)
Don't know if this is related, but encountered another bug when adding a tie across a barline. Immediately after adding the tie, Musescore changes the note before the barline to a note with the summed duration (while this should normally not fit the bar!). For example, when tying an 8th in bar 1 to a 4th in bar 2, Musescore changes the 8th note to a dotted 4th note in bar 1.
@cedricdeboom I can't reproduce that. Does that happen in this specific MusicXML file, or in a different file? Might it be possible that you accidentally enabled this setting:
