Global 4/4 against Local 6/4 generates errors

• May 15, 2016 - 19:50
P1 - High
S3 - Major

(In response to

Using MuseScore 2.0.3 Appimage on Ubuntu Trusty. See attached .MSCZ and .XML files.

Create a 2 part score with 4/4 global time signature and 6/4 local time signature on staff 1.
At staff 2, bar 1, enter 5 bars of quarter and half notes.
Change staff 2 bar 6 to local time of 12/8
At staff 2 bar 6 enter 2 bars of eighth notes.
At staff 1 bar 6 enter 2 bars of quarter notes

Save to XML.
Clear all open files.
Load saved XML file and see error message about corrupted files.

Additional testing generates the same error when 2 bars of 6/4 local against 4/4 global notes are entered without later adding 12/8 local time.


Yes, I think critical is the proper priority. Thanks.

The original discussion that led to this issue posting is at (ETA: Ooops. I see the OP already listed that link.)

One of the first questions that needs to be answered is if the bug is in MuseScore itself (we know there ARE bugs related to the use of local time sigs, and some of them are fairly nasty), or in the XML conversion module.

Note comment #1 seems to say a problem also happens when exporting to midi. The implication is that the source of the problem is not in the XML code.

With respect to the MusicXML import/export, this behaviour is simply a result of the fact that support for local time signatures has not been implemented yet. This leads to:

- incorrect export (note types are incorrect, measures are corrupt)
- corruption messages when importing this file
- if the exported MusicXML file is corrected and imported, it is imported incorrectly

Note that the last issue is by design: the import still assumes equal time signatures for all staves (which was a requirement before MuseScore supported local time signatures). This will have to be changed, of course.

Although I am familiar only with the MusicXML import/export (I wrote about 90% of it), I strongly suspect remark #4 is incorrect.

@Recorder485, I can try to resolve at least the export part quickly, which would prevent retyping your music.

If you could do that, it would be greately appreciated. Note that I am still using 2.0.1 (for a number of reasons), and Win7 Pro.

Note also that I am NOT competent to re-compile or modify the existing code in my resident version of the program. For me to use your proposed fix, I would need a link to the 'nightly' containing it.

I am not seeing the problem with MIDI. Sure, the result after export / import doesn't resemble the original, but that shouldn't be surprising - MIDI was never meant to convey those sorts of details.

Fix for export part of this issue available in pull request #2606. Should appear in a nightly build soon.

As the import part is not fixed yet (which takes more effort), the resulting MusicXML file is still (incorrectly) reported as corrupt by MuseScore. It does, however, import correctly into Finale Notepad.

@recorder485, it seems we currently only provide nightly builds for master (the 3.0 to be), which suffers from different MusicXML issues due to large recent changes. I do have a working 2.0.x available, but only for OS X. If the nightly builds don't work for you and you could mail me your mscz file, I could convert it to (hopefully correct) MusicXML for you.

Severity S3 - Major S1 - Blocker
Frequency Once
Priority P1 - High
Regression No
Reproducibility Always
Workaround No