Re: Obscure melisma fail

[David Kastrup]

tisimst <address@hidden> writes:

> On 9/9/2015 10:57 AM, David Kastrup [via Lilypond] wrote:
>> David Kastrup <[hidden email] 
>> </user/SendEmail.jtp?type=node&node=180901&i=0>> writes:
>>
>> > Here is the difference: The first variant adds the lyrics to \new Staff
>> > \altoOneVoice.  The second variant adds the lyrics to { d'2 ... } even
>> > _before_ \relative is called.  \addlyrics is sort of sticky.  Once the
>> > \addlyrics is sucked _into_ the \relative, it does not have a chance to
>> > combine with \new Staff in a useful manner.  So basically you get
>> >
>> > \score {
>> >   <<
>> >      \new Staff \relative << \new Voice="xxx" { d'2 ... cis}
>> >                              \new Lyrics \lyricsto "xxx" ... >>
>> >   >>
>> > }
>> >
>> > Or something like that.  Lesson: \addlyrics is for simple cases.
>> Here is the output after making \displayLilyMusic stupid about
>> \addlyrics and somewhat more \verbose about the result of \relative:
>>
>>
>>
>> altoOneVoice = \relative {
>>    d'2\melisma e4\melismaEnd cis
>> }
>>
>> altoTwoVoices = \relative {
>>     <<
>>       { d'2\melisma e4\melismaEnd cis }
>>       \new Voice { \voiceTwo s1 }
>>     >>
>> }
>>
>> altText = \lyricmode {
>>     side, sit
>> }
>>
>> \markup \column { "One voice in a music variable" "(center-aligned 
>> melisma)" }
>> \score {
>>   \displayLilyMusic
>>     <<
>>       \new Staff \altoOneVoice
>>       \addlyrics \altText
>>     >>
>> }
>>
>> % same music as above, but explicitly written out in the \score block
>> \markup \column { "One voice explicitly written out in \score block"
>> "(left-aligned melisma)" }
>> \score {
>>   \displayLilyMusic
>>     <<
>>       \new Staff \relative {
>>         d'2\melisma e4\melismaEnd cis
>>       }
>>       \addlyrics \altText
>>     >>
>> }
>>
>>
>> /usr/local/tmp/lilypond/out/bin/lilypond bibo.ly
>> GNU LilyPond 2.19.27
>> Processing `bibo.ly'
>> Parsing...
>> << << \new Staff = "uniqueContext0" \absolute { d'2 \melisma e'4 
>> \melismaEnd cis'4 } \lyrics \lyricsto "uniqueContext0" { side, sit  } 
>> >> >>
>>
>> << \new Staff \absolute << \context Voice = "uniqueContext1" { d'2 
>> \melisma e'4 \melismaEnd cis'4 } \lyrics \lyricsto "uniqueContext1" { 
>> side, sit  } >> >>
>
> David,
>
> This is a great explanation and almost exactly what I suspected after 
> reading through the comments in the parser.

After looking through the parser definitions, it does appear to me that
this case (music function call) is supposed to _not_ absorb \addlyrics
by default.  However, I am skeptical that one can achieve that purpose
with the approach used there.  I think that to achieve _that_, one would
likely have to list a few cases explicitly that are supposed to allow
\addlyrics rather than have it be something akin to a general feature
you can tack onto music and hope one can sort the problems out by using
operator precedence.

> Anyways, quark explained, but also raises some questions about how using 
> variables affects the internal representation of the data. I'm certainly 
> not concerned with it, but it still is curious. Has anyone found other 
> instances where this causes problems? (maybe this opens a bad can of 
> worms...)

In this case, it is not really the variable affecting the internal
representation of the data: it is just that the use of the variable
makes it impossible for LilyPond to group stuff in a bad way since it
cannot attach the \addlyrics to some internal part of the variable.

> Thanks, as always, for your excellent work and explanations.

Well, in this case it would seem that the work has been flaky.  Now
\addlyrics provably never worked as intended before I set to work on it:
the code path supposed to attach to an existing context definition
contained some typo that would have triggered a Scheme error when it
ever would have been called.

So this went from "works never as intended" to "works sometimes as
intended".

-- 
David Kastrup