[MusicXML] Repeat measure sign not exported or imported

I'm noticing this as well in 2.0 release.

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.

This has simply never been implemented, thus it is a feature request instead of a bug.

That means it's not a regression, but it's undoubtedly a bug.

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

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.

My apologies. Realistically, calling it a feature request does make just as much sense, so let's keep it in that category.

as I was investigating #10220: Add a two and four measure (multi-measure) repeat sign with playback 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:

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.

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 ?

What happens is it produces a series of multi-measure repeats. For instance if Y=4 measures, Z=2, then Finale NotePad when load the xml produces two two-measure repeats.

*It produces a series of multi-measure repeats is Y>Z and Y is a multiple of Z*

And if Y is not a multiple of Z then it produces a "hanging" sign:

Further example of import two-meas-followed-by-3-meas-of-repeat-size2-then-two-meas.xml into finale notepad, which shows the two-measure repeat symbol hanging at the end when Y is odd:

Some files created with Finale 2012 and Sibelius 7.
https://musescore.org/sites/musescore.org/files/issues/measure_repeat_F…
https://musescore.org/sites/musescore.org/files/issues/repeat_sib.zip

It seems that Finale NotePad can export a hairpin under a measure repeat:

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:

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.

"be generous in what you accept and strict in what you generate"

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.

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?

While working on this, how about using the fonts' glyphs for measure repeats rather than drawing them manually? See https://musescore.org/en/node/149901

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

Related to #270643: [EPIC] MusicXML import/export issues and came up again in #289724: Measure repeats not exported to musicxml

Changing the status to Active since there's no way the PR could work today.

Again in https://musescore.org/en/node/302344

Came up again in https://musescore.org/de/node/320621

This isn't fixed in master?

Is it?
Can't really test this currently, as XML Import doesn't work, see https://github.com/musescore/MuseScore/issues/7686

It seems to work though. Load Xote_Swing_single_instrument_3.1.mscz into a master build, export as musicxml -> Xote_Swing_single_instrument_4.0.musicxml
Import that into 3.6.2: while there are no measure repeats, the measures are not emüpty either, they just have the repeated content.
Then load Xote_Swing_single_instrument_3.1.mscz into a 3.6.2, export as musicxml -> Xote_Swing_single_instrument_3.6.musicxml. Import that in either 3.6.2 and see empty measures

I've been converting lots of scores into Musescore via MusicXML and I've noticed missing repeat signs. I always assumed that it was due to faulty MusicXML export, and the matter was easy enough to fix so I didn't check the MusicXML.

However, recently a score had so many missing repeats it was hard to tell where they belonged. So I will try to locate that XML, or investigate the next a repeat goes missing.

As mentioned, it seems fixed in master, but importing there is not possible currently, so we can't say for sure

As of Version 3.6.2 it appears that measure repeat signs are still not exported. Are there any plans to implement this fix?

If it's an issue of the measure repeat sign not actually a part of the MusicXML spec (i.e. it's notation exclusive to MuseScore) one workaround might be to fill in the repeated measure with the actual notes themselves.

Checked master, import seems to work, just wait for 4.0 to appear.

Note that this issue seems to be fixed as part of #10220: Add a two and four measure (multi-measure) repeat sign with playback (pull request https://github.com/musescore/MuseScore/pull/6365).

Export should be fixed there too

Automatically closed -- issue fixed for 2 weeks with no activity.

Sorry, just found this has been closed before I meet this in a Gershwin score. I just tested with V4, and it works as copying the previous measure. THis is a solution, but I don't know what will happen when meeting dynamics or other directional things like texts. However, the standard xml equivalent of this repeat should be (the same attached example exported from Sibelius):

       <measure number='2'>
            <attributes>
                <measure-style>
                    <measure-repeat type='start'>1</measure-repeat>
                </measure-style>
            </attributes>
            <note>
                <rest measure='yes'/>
                <duration>1536</duration>
                <voice>1</voice>
            </note>
        </measure>

If there are more measure after bar 2:

       <measure number='3'>
            <attributes>
                <measure-style>
                    <measure-repeat type='stop'>1</measure-repeat>
                </measure-style>
            </attributes>

If not, just end the score normally.
I looked into the repeat palette, and found there's only one type of such repeats. The possible types can be repeating last one, two and four measures, and the measure-repeat value should be 1, 2 and 4.

Haipeng

Came up again in #333146: <measure-repeat /> is not handled