Just found an excellent example of the ‘look at what the compiler does’
principle.
Demo file 04b-Glissando.xml contains:
<measure number="2">
<note>
<pitch>
<step>G</step>
<octave>4</octave>
</pitch>
<duration>1</duration>
<voice>1</voice>
<type>quarter</type>
<stem>down</stem>
<notations>
<glissando line-type="dashed" number="1" type="start"/>
</notations>
<lyric number="1"><text>dashed</text></lyric>
</note>
<note>
<pitch>
<step>F</step>
<octave>5</octave>
</pitch>
<duration>1</duration>
<voice>1</voice>
<type>quarter</type>
<stem>down</stem>
<notations>
<glissando line-type="dashed" number="1" type="stop"/>
</notations>
</note>
There’s no lyrics attached to the F, but all of MuseScore, Finale and
musicxml2ly interpret the glissando stop in that case as a skip in the lyrics:
An there too, no mention of this in note.mod:
<!--
Glissando and slide elements both indicate rapidly moving
from one pitch to the other so that individual notes are not
discerned. The distinction is similar to that between NIFF's
glissando and portamento elements. A glissando sounds the
half notes in between the slide and defaults to a wavy line.
A slide is continuous between two notes and defaults to a
solid line. The optional text for a glissando or slide is
printed alongside the line.
-->
<!ELEMENT glissando (#PCDATA)>
<!ATTLIST glissando
type %start-stop; #REQUIRED
number %number-level; "1"
%line-type;
%dashed-formatting;
%print-style;
>
A nice day!
JM
> Le 28 juin 2018 à 10:35, Jacques Menu Muzhic <imj-muz...@bluewin.ch> a écrit :
>
> 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>
>
> 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:
>
> <MuseScoreRepeatsWithBarNumbers.png>
>
> 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.
>
>
> 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
> >
>
> 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’).
>
> To be fair, it is known that describing the semantics of a computer language
> in a complete and consistent manner is quite difficult.
>
> Decades ago, that was done for Algol-68, which resulted in a textual formal
> specification a great number of pages.
> An anecdote: Laurent Trilling, one of the tenants of this language, told me
> that part of a night was spent by attendants of an Algol-68 conference trying
> to determine the semantics of a given code snippet, which was not clear. That
> took time, but the formal specification finally gave the answer!
>
> JM
>
>
>> Le 28 juin 2018 à 02:18, David Wright <lily...@lionunicorn.co.uk
>> <mailto:lily...@lionunicorn.co.uk>> 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 <lily...@lionunicorn.co.uk
>>> <mailto:lily...@lionunicorn.co.uk>> 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
>>>>> <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.
>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
