MU 4.0.2 nightly crashed
What I did using MuseScoreNightly-230270506-4.0.2-3e9f131-x86_64 on Windows 11:
1. Opened score
2. Looked at sax parts in measures 57 and 59.
Note: I've been working around the playback limitations of gliss'es using hidden elements in voice 2. See also measures 46-50.
3. Visited first 4 parts (Alto 1, Alto 2, Tenor 1, Tenor 2) and set zoom to 75%.
4. Still looking at the Tenor 2 part, I think I adjusted the length of the gliss. in measure 58. (After reopening the file, the gliss. appears to be adjusted.)
4. Went back to Tenor 1 part and lengthened gliss. in measure 58. MU crashed.
This is probably related to my crashes reported in [#343461] where the problem appears to be that MU 4.0 corrupts the measure numbering. When I tried to recreate this crash, I noticed that the indicated measure numbers in the score were incorrect, with too many beats in indicated measures. However, the measure were painted correctly. I joined and split measures 2 and 3 which forced renumbering the measures and restored the indicated numbering for the score, but the parts had an extra measure, with 8 beats, after measure 3. I had been experimenting with MuseScoreNightly-230260506-4.0.2-68b18e4-x86_64 and the above version, so the initial measure number problem could have happened in either version, but probably in 68b18e4.
I had been pursuing workarounds for the problem in #342864: Copying measures with not visible elements may ignore visibility when displaying some elements. "Copying complicated measures may ignore visibility when displaying some elements". That problem, which was also in 3.6, also affected the implicit copying to parts.
I found that MU 4.0 appears to have an additional problem with parts in that sometimes the part gets nothing, not even the visible elements when copying such a measure in the score.
Attachment | Size |
---|---|
Shiny_Stockings.mscz | 472.91 KB |
Comments
Please report this on GitHub
In reply to Please report this on GitHub by Jojo-Schmitz
On GitHub, I created #16116 for the "inserting measures at the beginning" and #16119 for this problem.