Global 4/4 against Local 6/4 generates errors
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
(In response to https://musescore.org/en/node/111211)
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.
| Attachment | Size |
|---|---|
| test_global_vs_local_time.mscz | 8.52 KB |
| test_global_vs_local_time.xml | 21.49 KB |
Comments
similar for the result with midi export:
Critical because this creates corrupt files.
Yes, I think critical is the proper priority. Thanks.
The original discussion that led to this issue posting is at https://musescore.org/en/node/111211. (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.
Still the case for current master. Should be addressed in 3.0.
This issue seems related to https://musescore.org/en/node/299817 and #299246: Hiding courtesy time signature only works for the first staff. Also in this example it hard to tell which is the global time signature and which is the local time signature.