On 2016-11-02 11:35, David Kastrup wrote:
Alexander Kobel <a-ko...@a-kobel.de> writes:
On 2016-11-02 11:20, David Kastrup wrote:
Alexander Kobel <a-ko...@a-kobel.de> writes:
I mostly set vocal music - typically clean SATB with exactly four
voices on either two or four staves, but sometimes a voice splits to
two or three in between. In that case, I'll almost always have a
four-staves situation. This screams for << \\ >> or << \\ \\ >>.
However, I attach lyrics to the voices, and that's why I give them
sensible names - namely, "sop" (or "soprano"), "alt", etc. The
implicit voice naming with << \\ >> means that I have to split my
lyrics to separate context, or I'll have to rename the voices inside
<< \\ >>.
No, it just means that your lyrics have to follow the staff rather than
a single voice unless your lyrics split as well.
Can't find the issue number where this was made to work. Still has
problems with overlapping melismata if I remember correctly, so maybe
that's why it's not advertised prominently.
Hum. You mean if I name the staff instead of the voices, I can create
lyrics that follow all voices that are active on this staff?
Doesn't seem to work, but I might not have the right syntax.
It's a 2.19 thing.
Post-2.19.49? Because that's what I tested with (without knowing what
syntax might be required, though):
\version "2.19.49"
sop = \relative c'' {
c4 c c c
<< { c c } \\ { g4. g8 } >> c4 c
}
\score {
<<
\new Staff = "sop" \sop
\new Lyrics \lyricsto "sop" { a b c d e f g h }
>>
}
test.ly:9:17: warning: cannot find Voice `sop'
\new Lyrics
\lyricsto "sop" { a b c d e f g h }
By the way, your reply to Werner shows pretty much what I actually
would consider useful: :-)
[...]
The problem I see right away with that is that it is useful. How is
that a problem?
<<
\new Voice = "soprano" {
...
\voices 1,soprano << ... \\ ... >>
...
}
\lyricsto "soprano" { ... }
Lo and behold, we have a solution for an old problem.
[...]
That one can actually be done sort-of right away. It would likely
cement the "2"/\voiceTwo/2nd item relation however. Which is sort of
the opposite of the proposal I started this discussion with.
I see, and totally agree. It's just something to keep in mind.
Cheers,
Alexander
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user