tisimst <tisimst.lilyp...@gmail.com> 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 _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond