[MusicXML] Repeat measure sign not exported or imported

• Jun 24, 2013 - 00:12
Type
Functional
Severity
S5 - Suggestion
Status
active
Regression
No
Workaround
No
Project
Tags

1. Open attached mscz (produced in 1.3).
2. 'Export...'.
3. Choose 'MusicXML'.
4. 'Save'.
5. Open MusicXML.

Result: Invisible rest appears in place of the 'repeat measure sign'.

Note: The exported MusicXML is also attached. See the entry at the MusicXML website.

Using MuseScore 2.0 Nightly Build (83197be) - Mac 10.7.5.


Comments

This problem still exists in version 2.0.2.

I'm not sure but I think repeat measure sign is not imported from a valid musicxml as well.

I think you are right that measure-repeat sign is not imported from a valid musicxml.

I've attached what I believe is a valid musicxml I created by exporting a two measure score and then using a text editor to change the second measure into a measure-repeat according to //www.musicxml.com/UserManuals/MusicXML/Content/EL-MusicXML-measure-repeat.htm which represents the measure repeat as "measure attribute" with a note of rest.

Importing this .xml in Finale NotePad 2012 correctly displays that second measure as a measure-repeat, while importing in MuseScore fails by displaying as a whole rest.

Seems to be both an import AND export issue, since MuseScore also fails when exporting a measure-repeat to .xml...I've verified this by first exporting a measure rest in musescore to xml, and then opening that xml in finale notepad, but do not see the measure-repeat.

Attachment Size
measure-repeat.xml 3.36 KB

We can argue over this for ages, I'm affraid. I don't see it being documented as a missing feature, so I see it as a bug by omission. But does it really make a difference?

It is only a bug if the code has been implemented but it does not perform as required.

Okay. The way I see it, MusicXML support has been implemented, but is not performing as required.

But once the request is fulfilled/bug is fixed, it won't matter. ;-)

Guys, Leon implemented the MusicXML importer/exporter and he is probably the one who will solve this issue. If he says it's a feature request, a bug or an apple, just agree with him and check another issue or assign yourself and write the code.

as I was investigating #10220: Add a two measure repeat sign I discovered that MusicXML uses the "measure-repeat" complex type for both *Single* measure repeats as well as apparently *any arbitrary number of measures*. Anyway, seeing that I will have to implement MusicXML import/export for that two-measure repeat, I will have to implement the single-measure repeat import/export at the same time, so I'm self-assigning.

argg..wait a minute I seem to have misinterpreted MusicXML's concept for start & stop...it seem that isn't specifying the number of measures in a multi-measure repeat, but rather just label the first measure and last measure of a consecutive series of single-measure repeats, at least according to:

http://usermanuals.musicxml.com/MusicXML/MusicXML.htm#EL-MusicXML-measu…

CORRECTION: I figured out how this xml measure-repeat works:

  • The very first measure of a series of measure repeats will begin with:
    {syntaxhighlighter xml}

    INTEGER

    {/syntaxhighlighter}
    Where INTEGER is "the number of measures to be repeated in a single pattern", which would be 1 in the example link above since it is using single-measure repeats, but that number could be 2 for two-measure repeats, 4 for four-measure repeats, or actually ANY number for any-sized measure repeats.

  • That first measure and subsequent measure-repeat measures will contain basically a filler note element, in the example is:
    {syntaxhighlighter xml}

    8
    1

    {/syntaxhighlighter}
    I guess rest measure="yes" would be used for filler for any-sized measure repeats as well.

  • The final measure of a sequence of measure-repeats will contain the measure-repeat type="stop" indicator:
    {syntaxhighlighter xml}

    {/syntaxhighlighter}

So basically any-sized measure repeats will work. And so instead of using a special barline for two-measure repeats (which display on the barline), it seems MusicXML instead just uses this start-stop measure-style format.

I'm confused is how start & stop works if there is only one measure with repeat measure symbol: |measureofnotes|%|anothermeasure|. The reason I'm confused is because the MusicXML attribute type start-stop can only take on the value of "start" or "stop", but not both simultaneously. If someone could send me an example MusicXML file of this situation generated from finale or sibelieus, then that would be appreciated.

I'm wondering for this case would the measure-style element for that measure repeat contain two measure-repeat elements, one of type start and one of type stop? Like:
{syntaxhighlighter xml}

1

{/syntaxhighlighter}

although I don't have any program capable of creating MusicXML files, I was about to manually type up an xml file to test
note-followed-by-two-measure-repeats.xml and then successfully opened in the free Finale NotePad 2012 (even though I don't seem able to create measure rests in finale notepad) which renders as: Screenshot (57).png

Note: it seems that the "stop" tag goes after the final measure of repeats, but in this case where there is no measure after the final measure of repeats, no stop tag could have been entered and finale didn't complain when importing this xml.

So it seems MusicXML is unable to represent the concept of a multi-staff part where only one staff has a measure repeat.

Here piano-one-measure-followed-by-measure-repeat-one-staff-only.xml on second measure starts a measure repeat. But since that measure repeat belongs to the whole measure, there is no way (to my understanding) for the xml to only have the measure repeat on one staff only. Also it seems that the "rest measure" note seems to be not necessary for the measure repeat. In face if I leave actual notes inside that measure, they are effectively ignored and are replaced by a measure repeat symbol upon import into finale.

Screenshot (58).png

wait, I think I figured out how to do measure repeat in only one staff. It seems measure-style has an optional attribute "number" of type "staff-number" which indicates staff numbers within a multi-staff part.
http://usermanuals.musicxml.com/MusicXML/Content/CT-MusicXML-measure-st…

attached are simple examples where the measure repeat is on one staff only.

apparently if number is not specific, then the measure-style applies to the entire measure for that part, although the measure repeat symbol will display on each staff.

Without claiming at all to understand the ins and outs of Music XML, I think you may be working harder than you need to on this. Two thoughts on that:

1. In the digital age with copy/paste available at the cost of a few keystrokes, it strikes me as extraordinarily lazy practise to use measure-repeats in some parts in a score while not in others. I run into this sort of thing all the time in 300-year-old baroque works--in separate parts, I hasten to add--but those were copied by hand by guys working at per-page rates and usually labouring under the gun to get the parts ready for a performance tomorrow night. (I know whereof I speak; I earned my beer-and-cigarette money by copying Broadway parts with a Speedball pen all through music school.) There is no legitimate reason to do it that way today; it is too fast and easy to copy a measure and then hit CTL+V as many times as needed.

2. I don't often work as a conductor, but when I do, I appreciate scores which are coherent in as many aspects as possible. It doesn't help a conductor keep track of what's going on if some parts have measure-repeats in them and others don't.

So, the question is, is it really important that MusicXML exports can deal with measure-repeats on some staves but not on others? I would say no; but others may disagree.

HTH; sorry if I've strayed out into left field on the issue....

I think that advice applies fine to users who are making charts. But MuseScore should support the import/export regardless of whether it is good chart-making practise.

I do think that the measure repeats are extremely useful in fitting a large piece that contains such repeating behavior into as few pages as possible. This is especially true for pop or jazz tunes where there is a repeating bass vamp or drum pattern that it copied out would take up too many pages.

Interesting. In Baroque music, we often come across such text notations as 'sempre il medemo basso' to indicate that the bass 'vamp' is to be repeated until the soloist gets tired of improvising new variations. ;o) Plus que ça change, plus que c'est la même chose.....

Also it seems that the "rest measure" note seems to be not necessary for the measure repeat. In face if I leave actual notes inside that measure, they are effectively ignored and are replaced by a measure repeat symbol upon import into finale.

Still this is incorrect according to the specs: The actual music being repeated needs to be repeated within the MusicXML file.

OHHH...now I get it!!! Will have to note-for-note copy from the source measure when exporting to MusicXML, although it seems when importing MusicXML, can ignore if is part of a repeat measure.

If I understand correctly, MusicXML can encode a sign with X slashes, spanning Y (start-stop) measures, with a text element (number of measures to be repeated in a single pattern) of Z.

How does that work if Z !=Y ?

It seems that Finale NotePad can export a hairpin under a measure repeat:
Screenshot (64).png

So I need to retract my statement #22 "it seems when importing MusicXML, can ignore if is part of a repeat measure" because after inspecting the xml hairpin.xml I see that their is a "wedge" element in that measure. So I'm trying to think what stuff can be ignored and what not ignored when importing? I'm guessing pretty much any line element (hairpins, pedals, voltas, etc), barlines, jumps, text, chordsymbols...I'm guessing everything except actual notes/rests need to still be imported in measure repeat measures.

I've also been investigation situation of one size of measure repeat stopping then immediately another size of measure repeating starting, like: Screenshot (65).png

I could manage to get Finale NotePad to import an xml file with changing behavior note-followed-by-measure-repeat-followed-by-two-measure-repeat.xml was if I put two attributes elements back to back in the measure...for instance here is measure 5:
{syntaxhighlighter xml}

1

{/syntaxhighlighter}

After exporting that from Finale note-followed-by-measure-repeat-followed-by-two-measure-repeat-after-finale-notepad-export.xml and inspecting the xml, I see that they merged the attributes element together:
{syntaxhighlighter xml}

1

{/syntaxhighlighter}

But flipping the start & stop order would cause import to not work. Also, trying to put both measure-repeat elements inside of one measure-style element would not work, e.g:
{syntaxhighlighter xml}

1

{/syntaxhighlighter}

So the take away point is that order of the "stop" & "start" is important within a measure (can't flip them), and also when exporting I'm going to stick to Finale's export style to ensure at least we're compatible with them.

I assume I can operate under the "garbage-in, garbage-out" principle, such that we don't need to worry about trying to import or trying to throw every imaginable type of error, if for instance the stop and start are flipped in a measure.

Well that sounds like a good general philosophy. But I'm not going to try to handle flipped stop & start in the same measure here since finale notepad doesn't seem to support it, unless someone finds that some important program accepts flipped stop & start.

note to myself: I was trying to figure out the best way to bypass the creating of note elements and anything else that shouldn't be in the multi-measure repeat zone...I think it would happen somewhere around here https://github.com/ericfont/MuseScore/blob/de0f267d2552f844e72f558049b2…
and then would want to create the single or multi measure repeat element here: https://github.com/ericfont/MuseScore/blob/de0f267d2552f844e72f558049b2…
I'll look more closely tomorrow.

got a single-measure repeat succesfully importing: https://github.com/musescore/MuseScore/compare/master...ericfont:21649-…

Question regarding input test files when including them in test codebase, if the xmls were generated from whatever program, they will have a bunch of tags specific for that program and default appearance info . Should I remove all that junk for the input test cases?nevermind, I see all the other test cases don't have extra junk.

mscore/exportxml.cpp doesn't have a corresponding .h file...should I split the class definitions into another file?

Also an aside question is what is the reasoning behind categorizing some files are inside mscore and others in libmscore? I would think mscore is for the gui application, while anything non-gui related, like this import/export code, should be in libmscore.

I'm looking at export code, and am thinking about when the spec says "The actual music being repeated needs to be repeated within the MusicXML file". I'm trying to think what type of stuff should not be put in measure repeat measures, even if they existed in the original source measure:

exclude:

  1. key sigs
  2. time sigs
  3. dynamics??
  4. spanners??

include:

  1. all notes & rests

maybe some of these are don't care. I'm guessing the reasoning behind including the original music in these repeat measures is so that the xml output is backwards compatible with some other notation program's musicxml import that might not understand measure repeats. I'm guessing the most important thing is to put in the chord-rests segments, but I don't know what other elements for sure need to be exported to the xml.

Thinking more, I'm guessing only all notes & rest from source measure should be copied to xml for the measure of a measure repeat. And any non-note elements from measure of measure repeat should be copied to the xml.

i'm going to try the approach of moving the measure export code: https://github.com/musescore/MuseScore/blob/master/mscore/exportxml.cpp… out of ExportMusicXml::write() and put in its own function. Then I'll let that code be called for a specific measure and have an option parameters "bool exportChordRests" and "bool exportNonChordRests".

Normal measure would export with exportChordRests=true and exportNonChordRests=true.

A measure repeat would first get the notes of the source measure by doing one pass through the source measure with exportChordRests=true and exportNonChordRests=false. Then would export the non-note elements of the measure repeat measure by doing a pass through the repeat measure with exportChordRests=false and exportNonChordRests=true.

I believe this is the desired behavior.

Also there is a big #if 0 ... #endif secion of code:
https://github.com/musescore/MuseScore/blob/master/mscore/exportxml.cpp…
which is making hard to read. If that is not being used any more, it would be easier to read if that was removed from codebase...I'm going to go ahead and remove that for now.

For the overall arch of MusicXML import/export, ping @lvinken in your pull request. He wrote the vast majority of the MusicXML code.

ok, well I made a preliminary work-in-progress pull request https://github.com/musescore/MuseScore/pull/2859

which seems to work for simple test cases, although I still need to do some things like avoid writing unnecessary "forward" tags to xml and test all sorts of cases. I don't really have questions for Leon Vinken...I believe I figured out the parts of the code that I needed to deal with. The main function I broke off from ExportMusicXml::write() is ExportMusicXml::writeMeasureContents() which I only really changed by adding if (exportNonChordRests) and if (exportChordRests) to selectively write notes or non-notes to xml.

Status (old) active patch (code needs review)

I'm marking as code needs review, because I'm passing my test cases and the ones lasconic provided. I will start working on layout & GUI.

I've added MusicXML i/o code to handle the optional "slashes" attribute for measure-repeat http://usermanuals.musicxml.com/MusicXML/Content/AT-MusicXML-slashes_1… ...about to repush -f to the PR...

I have a workflow question: Since I believe I'm basically done with the MusicXML i/o code, which is what this issue is about, then should I finalize this PR and squash the commits, and then work on layout & gui as a separate PR based off of this PR? Or should I just keep adding to this PR?

Reported version 2.1  
Regression No
Workaround No

Sorry to resurrect a dead thread, but this bug still appears as of Musescore 3.0.5.