Staff properties corrupted on MusicXML import after Master Palette opened
Reported version
3.0
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
Import the attached musicxml.musicxml file. This is a musicxml exported by MS3 from the attached musicxml.mscz
Expected result:
Actual result:
Workaround1: Set staff properties: number of lines, show key, show clef
Workaround2: Save, close and reload the imported file
Attachment | Size |
---|---|
musicxml.mscz | 2.01 KB |
musicxml.musicxml | 2.4 KB |
Comments
Which build of MuseScore shows this problem? Opening the MSCZ file in the "alpha 2" build, exporting as MusicXML, and importing the result works fine. So does simply opening the MusicXML file provided.
In reply to Which build of MuseScore… by Marc Sabatella
Reproducible in Mac build 2018-10-31-1202-3.0alpha2-3abd82b.
Self compiled
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 3543170
In reply to Self compiled OS: Windows 10… by tobik
Try this:
1. Open musicxml.musicxml. If it looks good..
2. Open Master palette.
3. At this point the time signature will vanish.
4. Close and reopen musicxml.musicxml.
5. Now it looks as the actual result screenshot above.
Interesting! I can confirm that opening the Master Palette causes the time signature to vanish. And that after doing that, each subsequent attempt to open the file causes the display glitch shown in the original post. Note that saving the musicxml is not needed. Closing MuseScore 3 and restarting it sets everything back to normal again, until you open the Master Palette.
So. full steps to reproduce:
1) start MuseScore
2) open Master Palette
3) close Master Palette
4) open musicxml.musicxml from original post
At this point, you get the display shown in the original post. If you right click and go to Staff Properties, you will see the staff is set to one line, and "Show time signature" is turned off.
So it seems somehow the Master Palette is interfering with the staff properties in scores imported from MusicXML. It seems reproducible with any MusicXML file, and I haven't seen this behavior with other scores.
Seems likely that there is some freed memory being overwritten, meaning I could easily imagine this not being reproducible in the same way on all systems, and could be different in debug vs release builds.
In reply to Interesting! I can confirm… by Marc Sabatella
Issue reproduces 100% reliable for me too (self built MuseScore master running on OS X), which seems to rule out memory corruption as a cause. I would rather suspect an error in the staff type initialisation in the MusicXML importer, resulting in the staff definition being shared with and modified by the master palette.
Interestingly enough, the issue does not occur for a percussion staff.
Changing the if statement at the end of MusicXMLParserPass2::clef() (replace "if (st == StaffTypes::TAB_DEFAULT ...)" by "if (true)") seems to solve the issue.
In reply to Issue reproduces 100%… by Leon Vinken
Yes, that fixed it for me too. Thank you!
Is someone turning it into a PR then?
I can do it. But I don't know if my PRs are going to be merged.
Well, seems that change is a bit over-simplistic?
Fixed in branch master, commit 1edd676aa7
fix #277699 Staff properties corrupted on MusicXML import after Master Palette opened
The problem is deep in the initialization of staff types in Staff.
This commit also tries to make handling of StaffType more "const correct" and adds some
assertions which may lead to crashes (and helps detecting bad code).
https://github.com/musescore/MuseScore/pull/4131
Automatically closed -- issue fixed for 2 weeks with no activity.