Guy Stalnaker <jimmyg...@gmail.com> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
