Exporting M4 file as an .xml file and Bar Properties

• Jan 26, 2023 - 10:10
Reported version
S2 - Critical

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.


Frequency Many Once
Status active needs info

Open .xml file (it defaults to M3) ??
Regression vs. what?
Can you attach score and xml?

Workaround No Yes

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!

Regression No Yes
Severity S3 - Major S2 - Critical

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.

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

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.

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