[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Obscure melisma fail
From: |
David Kastrup |
Subject: |
Re: Obscure melisma fail |
Date: |
Wed, 09 Sep 2015 20:32:11 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
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
Re: Obscure melisma fail, David Kastrup, 2015/09/09