lilypond-devel
[Top][All Lists]
Advanced

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

Re: Notation Reference doc addition: Techniques Specific to Lyrics


From: David Kastrup
Subject: Re: Notation Reference doc addition: Techniques Specific to Lyrics
Date: Sat, 09 Mar 2013 17:50:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Guy Stalnaker <address@hidden> writes:

> Add to this page after the section for Divisi lyrics at the bottom:
>
> http://lilypond.org/doc/v2.16/Documentation/notation/techniques-specific-to-lyrics
>
> The following is based on this page for Temporary polyphonic passages.
>
> http://lilypond.org/doc/v2.16/Documentation/notation/multiple-voices
>
> Addition:
>
> It is common in choral music to have a voice part split for a cadence,
> or a measure or two. The << {...} \\ {...} >> construct, where the two
> (or more) musical expressions are separated by double backslashes,
> might seem the proper way to set the split voices. This construct,
> however, will assign *all* the expressions within it to *NEW Voice
> contexts* which will result in *no lyrcis* being set for them since
> the lyrics will be set to the original voice context--not, typically,
> what one wants. The temporary polyphonic passage is the proper
> construct to use.

Adding to this posting on the bug list, let me outline a bit of a plan:
exactly this problem was the trigger for
<URL:http://code.google.com/p/lilypond/issues/detail?id=3225>.

Now the normal coordination of announce and acknowledge and listener
methods is not quite suitable for some sort of subcontext like a
prospective SubVoice.  It is, however, rather important to note that
this coordination is not actually hardwired but rather a consequence of
the Voice context's _translator_ _group_ (specified using \type in
context definitions).

The orchestration for Engraver_group is done in lily/engraver-group.cc,
and there is nothing precluding the creation of a separate more suitable
behavior for subcontexts in a separate translator group possibly called
lily/engraver-subgroup.cc or similar (likely also requiring a
Performer_subgroup).  So it would be conceivable to censor announcements
in a subgroup and let only those escape upstairs for which there is no
listener/acknowledger downstairs.

If \\ split material suitably into subvoices (with their own engravers
for notecolumns, slurs and a few other things), then stuff like the
lyric problems and unfinished ties and similar might possibly get
reasonably working solutions.

That's just a sketch of proceeding, and there are more open than
answered questions.  But it could provide an interesting take on this
problem.

-- 
David Kastrup



reply via email to

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