MusicXML import of local 3/4 and 9/8 local time signatures

• Jan 3, 2021 - 10:11
Reported version
S5 - Suggestion

in questa partitura ci sono due cori uno adunata certo punto cambia il tempo da 9/8 a 3/4 ma la riproduzione non è corretta e neanche la notazione. Inoltre restano sempre pause sparse per lo spartito. questo avviene anche con partiture nuove caricate direttamente dall'applicazione

Attachment Size


Frequency Many Once

Google translate:
in this score there are two choirs one gathering certain point changes the time from 9/8 to 3/4 but the reproduction is incorrect and neither is the notation. In addition, there are always scattered breaks for the score. this also happens with new scores uploaded directly from the application

Translation doesn't seem to make much sense...
I see a time sig change to 3/4 for the bottom choir in measure 9, and that meadsure being marked as irregular.
Also you made the typical mistake on not starting with voice 1 in every staff

The score has been produced converting an XML from Finale. In Finale the two chorus line are written and excuted correctly. MuseScore has converted from XML the same scores formally correctly but if you try the execution the 3/4 notations does not take effect and not follow the 9/8 scores. I hope You forgive my very bad english... tks

Title 3/4 and 9/8 [XML-Import] 3/4 and 9/8

So the XML would be needed in order to investigate what MuseScore might be doing wrongly with it

Title [XML-Import] 3/4 and 9/8 MusicXML import of local 3/4 and 9/8 local time signatures

I'm not an MusicXML expert, but this file may not be correct, it shows the time signature change on two staves only. Unless that was the intent - to create a "local" time signature of 9/8 on the top staves and 3/4 on the bottom? I definitely don't know how MusicXML represents that or if we support import of local time signatures.

Frequency Once Few
Regression No Yes
Reproducibility Always Randomly
Severity S5 - Suggestion S3 - Major
Type Functional Development
Reported version 3.5 4.0

the new vwrsion 4.0 sometimes is not able to import an mxl file that version 3.0 import without problem.

Attachment Size
emmaus.mxl 7.4 KB
Frequency Few Once
Regression Yes No
Reproducibility Randomly Always
Severity S3 - Major S5 - Suggestion
Type Development Functional
Reported version 4.0 3.5

I don't see local time sig in that score, so it got to be a different issue

3.6.2 claims it to be an invalid musicXML file:
Fatal error: line 126 column 96 Element measure-numbering contains unknown attribute multiple-rest-always.
My 3.7.0 though loads it without issue (except for loosing the "Largo")

But you're right, 4.0.2 as well as the latest development builds don't load it (it does load the OPs file though)
Well, it does load it, but for some reason with invisible staves, 'opening the eyes' helps here.
Open an issue on Github about this

To the OP: you too should better open an issue on GitHub, about the local time sig import

This issue tracker here has been discontinued, so now use