Bug: XML Export - Measure length within Multimeasure rest changing
When you create a new part that contains a multimeasure rest and export it as XML, each measure within the multimeasure rest has a length of "0.00". Back in MuseScore, you can press "M" to break the multimeasure rest up, and press "M" again to toggle multimeasure rests on again. After doing this, export to XML again, and now each measure within that multimeasure rest will have it's original length (in this example it's "163.92" for M.6 and "135.24" for M. 7-13).
Saving the .mscz file has no effect. You have to close and reopen the file and export again in order to achieve the "0.00" length for those measures.
| Attachment | Size |
|---|---|
| MultiMeasure_Test.mscz | 5.05 KB |
| MultiMeasure_Test-Flute after M twice.xml | 7.58 KB |
| MultiMeasure_Test-Flute fresh.xml | 7.27 KB |
Comments
Since multimeasure rests are enabled, does it actually cause some sort of problem for the underlying measures to have a length of 0? Internally, these measures have no been laid out yet and thus they do in fact have a length of 0, so the export is technically correct. But there are some problems that result from this fact and we have been fixing them one by one, I kind of wonder if the better fix isn't to just force the underlying measures to be to be laid out once when the first is first loaded / created. That would fix your problem as well. But it would help to understand the actual problem you are seeing as a result of this.
In reply to Since multimeasure rests are… by Marc Sabatella
The multi measure rest encoding in MusicXML consists of one measure marked with measure-style multiple-rest, followed by "dummy" measures (the remaining measures in the the multi measure rest, which are not visible in the score). Thus it seems logical that the first measure marked with measure-style multiple-rest gets the width a determined by the actual layout and the following ("dummy") measures get width 0. This is the also way Recordare's Dolet plugin encodes it.
In the attached files, I would expect measure 6 to have a non-zero width and measures 7 up to 13 ti have width of zero. So to me both MultiMeasure_Test-Flute fresh.xml and MultiMeasure_Test-Flute after M twice.xml seem incorrect.
In reply to The multi measure rest… by Leon Vinken
The way you described what should be happening made a bunch of things make sense now. So the length of the dummy measures doesn't really matter, but the length of the first measure does. When you upload either of these files back into MuseScore, they both work fine because MuseScore automatically stretches the multimeasure rest to cover the whole length of the system, no matter what number is put as the width for that first measure. SmartMusic on the other hand is not as smart.
SmartMusic reads the width of that first measure of rest ("0.00" or "163.92" depending on which file you use) and doesn't stretch it out. See "MM Rest Length Original.png".
I think what should happen in this instance is Musescore should be giving M. 6 a length of "1110.61" (the width of the whole system) and M. 7-13 can all be "0.00". I manually made this change, and SmartMusic was happy. See "MM Rest Length Adjusted.png".
Btw, I've tested other files I have with multimeasure rests and by default it always sets that first measure as "0.00"...until you press "M" twice.
In reply to The way you described what… by Andrew S
This is a more dramatic example of what happens when MuseScore doesn't give the first measure of multimeasure rests the specific width that matches what MuseScore is displaying onscreen.
In reply to The way you described what… by Andrew S
I just discovered that the first measure of a multimeasure rest being set to "0.00" width is also the reason why double barlines before multimeasure rests weren't showing up in SmartMusic.