Staff properties corrupted on MusicXML import after Master Palette opened

• Nov 1, 2018 - 12:25
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:
musicxml-export.png

Actual result:
musicxml-import.png

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.

Title Missing staff properties after MusicXML import Staff properties corrupted on MusicXML import after Master Palette opened

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 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.

Status active fixed

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).