Exporting M4 file as an .xml file and Bar Properties
Reported version
4.0
Type
Performance
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
active
Regression
Yes
Workaround
Yes
Project
Create file in format SATB plus piano in 4/4 music tempo with notes in each stave
Export as .xml file
Open .xml file (it defaults to M3)
Note the bar properties have not exported correctly. Bars with 4/4 tempo now have a grayed out + sign in each bar indicating Bar Properties have changed and are now 8/4 or something else other than 4/4 .
Accessing Bar Properties to correct the tempo in each bar erases the notes in the piano bass clef stave.
Comments
Open .xml file (it defaults to M3) ??
Regression vs. what?
Can you attach score and xml?
Export the four voices as .mxl files, then export the piano part in a separate .mxl file, open each in M4, edit the voice files to create piano staves then copy and paste the piano part into the four voices file. That works but it's a hell of a lot of cutting and pasting!
The score stems from 4.0, so it got to be a 4.0 issue
Relates to #270643: [EPIC] MusicXML import/export issues
And indeed is a regression vs. 3.x
Loss of information/corruption (sort of), hence Critical
This may help identify the source of the problem. I've created a specific .mscv file for the piano score, and that exports perfectly as an .mxl file. I've done the same for the SATB file and that exports perfectly as an .mxl file too. The problem only occurs when exporting the SATB plus piano file.
.
The file exported is lacking the required divisions element, this is an export issue.
Root cause is the non-standard measure numbering, which causes function MeasureNumberStateHandler::isFirstActualMeasure() to fail. May very well also apply to MuseScore 3 (will check).
In reply to Root cause is the non… by Leon Vinken
Well done! I've been using M3 regularly since it's issue and never had this happen before. Thanks for identifying the cause.
Issue does not occur in MuseScore 3, it was introduced in MuseScore 4 with commit f90880a on Dec 5, 2021. See void MeasureNumberStateHandler::updateForMeasure(const Measure* const m), which should distinguish between logical and displayed measure numbers.
So it is that
_measureNo += m->noOffset();from f90880a ?If so, my PR #9000 should also be affected
I'm confused now, loading your mscz into 4.0.1 starts with measure 58, that does seem correct to me.
Importing the mxl into 4.0.1 also shows that the score starts with measure 58, as does my 3.7.0, but not 3.6.2, so that's apparently the bug fixed by above mentioned commit.
But indeed the MXL import in all cases (4.0.1, 3.7.0 and 3.6.2) show those 'corrupt' actual measure durations. So I'm at a loss to understand how that commit could be the culprit?
I can confirm though that it is an XML Export issue with 4.0.1 (and 3.7.0 too)
I can further confirm that deleting/commenting that line fixes the actual measure number issue, but reintroduces the wrong measure number offset one
The issue is on the export side, where commit f90880a (which introduces irregular measure numbers) breaks the decision to write the MusicXML divisions element. As a result the exported MusicXML file imports incorrectly because (with divisions missing) the backup element cannot be interpreted, which results in all voices being concatenated instead of parallel. Fix still to be created, simply removing the line added to exportxml breaks irregular measure number export.