bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The built-in template satb.ly fails in 2.19.16


From: David Kastrup
Subject: Re: The built-in template satb.ly fails in 2.19.16
Date: Sat, 14 Mar 2015 14:25:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Saturday, March 14, 2015 7:28 AM
>
>
>> "Trevor Daniels" <address@hidden> writes:
>> 
>>> I've just noticed that the examples of using the built-in template,
>>> satb.ly, in the Learning Manual, see
>>> http://www.lilypond.org/doc/v2.19/Documentation/learning/built_002din-templates
>>> are not correct in 2.19.16.
>>> Does anyone recognise any changes in 2.19.16 which might have
>>> affected this macro?
>>> (There have been minor changes to this in current master, but both
>>> fail the same way.)
>> 
>> Pretty likely issue 2010
>> <URL:https://code.google.com/p/lilypond/issues/detail?id=2010>.
>> 
>> I think it requires associated voices to either be in the same << >>
>> block as their lyrics.  Or something like that (if they are not
>> accompanied by any non-associated context in the << >> I think that's
>> also ok).
>
> That seems to be it, sort of.  Below I've simulated the
> rather bizarre structure the satb.ly template generates.
> This causes the last three notes of the Soprano line and
> all the lyrics to vanish, although no error is generated.

Well, the solution to issue 2010 kills off associated lyrics contexts
when they become (rather than already are) the only thing left in a
<<...>> construct.  But in this case, the controlling context is
actually outside.  The problem of 2010 was that if the controlling
context in a <<...>> construct dies, the associated lyrics have to quit
at the same timestep rather than wait for another timestep, or the
<<...>> construct will throw the whole timing of LilyPond off.

I'm not sure there is a sane way within the current design (which uses
the run_always flag for associated lyrics) to make this work in
arbitrary complex <<...>> constructs.

Maybe there is a better solution for issue 2010 but I've spent a _lot_
of time playing around with that one.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]