Re: Repeat question

[David Wright]

On Thu 28 Jun 2018 at 10:35:49 (+0200), Jacques Menu Muzhic wrote:
> Hello David,
> 
> I downloaded the LilyPond Unofficial Test Suite at the time when the links to 
> in lilypond.org <http://lilypond.org/> were dead (I’d say 2.5 years ago), 
> can’t remember where that was from, probably from the GIT repository. Don’t 
> know whether 45d-Repeats-Nested-Alternatives.xml changed between versions of 
> LilyPond.
> 
> The hookless alternative at measure 12 and the extra measure at the end I 
> added two days ago, following Torsten’s answer.
> 
> The 8 comes from:
> 
>     <measure number="12">
>       <barline location="left">
>         <ending number="8" type="start"/>
>       </barline>
>       <note>
>         <pitch>
>           <step>G</step>
>           <octave>5</octave>
>         </pitch>
>         <duration>4</duration>
>         <voice>1</voice>
>       </note>
>       <barline location="right">
>         <ending number="8" type="discontinue"/>
>       </barline>
>     </measure>

Oh, OK. I'm not sure it helps, and I still don't understand the "8"..

> The difficulty with this file is that there are nested repeats, and it’s not 
> obvious what its semantics is.
> 
> On the MuseScore output below, with bar numbers displayed:
> 
> 
> 
> I guess the measures are to be played in this order:
> 
> 1 2 
> 1 3 4 5
> 1 6 7 8 9 10 
> back to beginning
> 1 2 
> 1 3 4 5
> 1 6 7 8 9 11 
> back to beginning
> 1 2 
> 1 3 4 5
> 1 6 7 8 9 12 13
> 
> Of course, there’s a risk of getting lost when playing such music.

It's not just the nested repeats, but the lack of consistency in the
notation used in the XML.

> The MusicXML 3.0 DTD does not help regarding this semantics question. 
> The only 3 occurences of ‘backward’ use for repeats are the following ones 
> (in barline.mod), and the fact that repeats can be nested is not mentioned. 
> The exact same text is in barline.mod in the 3.1 DTD:
> 
> <!--
>       Repeat marks. The start of the repeat has a forward direction
>       while the end of the repeat has a backward direction. Backward
>       repeats that are not part of an ending can use the times
>       attribute to indicate the number of times the repeated section
>       is played. The winged attribute indicates whether the repeat
>       has winged extensions that appear above and below the barline.
>       The straight and curved values represent single wings, while
>       the double-straight and double-curved values represent double
>       wings. The none value indicates no wings and is the default.
> -->
> <!ELEMENT repeat EMPTY>
> <!ATTLIST repeat
>     direction (backward | forward) #REQUIRED
>     times CDATA #IMPLIED
>     winged (none | straight | curved | 
>               double-straight | double-curved) #IMPLIED

I was under the impression that the business of XML is to capture the
appearance of the music faithfully, regardless of what it means.

> So yes, MusicXML semantics is somewhat of a fuzzy target, and you have to 
> look at what some existing tools do to tackle that, which is what I do (the 
> good old ‘look at what the compiler does’). 

Presumably, the crunch comes for WYSIWYG programs when they output the
MIDI because that reveals the semantic decisions made. With LP, we can
also examine the source generated. But it means there could be a
plurality of interpretations.

> To be fair, it is known that describing the semantics of a computer language 
> in a complete and consistent manner is quite difficult.

Programs are far more complex that a piece of music.

It would be tedious but I could write a score in MusicXML that makes
no musical sense, but is it productive to then use it as a test?
Alternatively, where is the "right answer" that these test snippets
are supposed to represent?

> > Le 28 juin 2018 à 02:18, David Wright <address@hidden> a écrit :
> > 
> > [I haven't reattached the images.]
> > 
> > On Tue 26 Jun 2018 at 18:22:00 (+0200), Jacques Menu Muzhic wrote:
> >> Hello David & Torsten,
> >> 
> >> The snippet file in my OP is actually a shortened version of a file 
> >> contained in the LilyPond Unofficial Test Suite.
> > 
> > Which version?
> > 
> >> 
> >> Adding the missing 
> >> 
> >>       <repeat direction="backward »/>
> >> 
> >> to measure 10 and a final measure 13, I obtain the attached file.
> > 
> > I don't see where the "8" came from.
> > 
> >> MuseScore 2.1.0 ignores <duration>, hence the quarter notes, but is 
> >> otherwise OK:
> > 
> > Could you give us the sequence of notes that this score represents.
> > I get as far as:
> > 
> > c' d' (1st ending)
> > c' e' f' g' (2nd ending, then a :| missing)
> > c' a' b' c'' d'' e'' (3rd ending's 1st ending)
> > c' a' b' c'' d'' (3rd ending's… ) f'' (2nd ending? "5"?)
> > c' (whither now?)
> > 
> >> Finale 2014 is OK, and I discovered on this occasion that the alternative 
> >> lines with 2 hooks, one a each end, are in fact two superposed lines, each 
> >> one with a hook at one end. Moving them apart give:
> > 
> > Should we have more colours? Which hook closes which volta?
> > 
> >> musicxml2ly does not do a good job in that case on alternatives 2 et 3:
> > 
> > What defines a good job? I assume I could replicate the MuseScore 2.1.0
> > with LP by using a few Score.repeatCommands (though I don't feel I'll
> > learn anything in the attempt) but in order to get useful LP code, one
> > has to decide what the score's semantics are. For me, duplicating the
> > notational syntax is a waste of time.
> > 
> >> Interesting!
> > 
> > Knowing little about XML, let alone MusicXML, I don't know how much of
> > the semantics of repeats can be expressed and enforced.
> > 
> >> Le 26 juin 2018 à 15:41, David Wright <address@hidden> a écrit :
> > 
> > [one spurious quote marker removed]
> > 
> >>> On Mon 25 Jun 2018 at 12:34:13 (-0700), Torsten Hämmerle wrote:
> >>>> Ok, when looking at the XML data, I'll have to admit that Finale, 
> >>>> Musescore
> >>>> and Sibelius (just tested it) are closer to the XML reality, whereas
> >>>> LilyPond fills in missing parts.
> >>> 
> >>> I'd agree, and would say that the XML is simply malformed, so the
> >>> musicxml2ly program is trying to correct it. AFAICT the output is
> >>> consistent with prioritising the earliest elements encountered in
> >>> the source, ie the volta brackets.
> >>> 
> >>>> Import into Sibelius:
> >>>> <http://lilypond.1069038.n5.nabble.com/file/t3887/sibelius-xml-repeat.png>
> >>>>  
> >>>> 
> >>>> But I think there's a 
> >>>>       <repeat direction="backward"/>
> >>>> missing in the XML file at the end of measure 2 (within <barline…>)
> >>>> 
> >>>> If you insert this, the missing repeat barline between the volta brackets
> >>>> will even show up in Finale/Sibelius/MuseScore. ;)
> > 
> > I didn't understand that then, and I don't now. Your .xml file posted
> > here seemed to have a whole ending (numbered 8) added to it.
> > 
> >>> But if you insert a :| at the end of bar 2, then the bar sequence
> >>> played becomes 1 2 1 3 1 4, so bar 4 still needs an open-ended
> >>> volta |¯¯ marked with 3 for third time (open-ended, assuming that
> >>> the single bar 4 is a placeholder for a passage of music).

Cheers,
David.