[EMAIL PROTECTED] writes:
> Hi, list. I'm working on tweaking \partcombine so that it can be used
> with \lyricsto for the purpose of typesetting hymns more easily. The
Cool!
> problem is that after \partcombine, the melody line (to which a lyric
> should be set) may be split between three (more?) separate voice
> contexts. Re-setting associatedVoice does not work 100% of the time,
> owing to the fact that one must re-set the property one syllable ahead
> of time. (This is clumsy even when not using \partcombine, and someday
> I'll have stared at the parser long enough to figure out how to fix
> this.)
Yes - this sucks, but we lack the infrastructure to make a nicer
solution.
> The following describes one solution that I'm testing. I've modified
> part-combine-iterator so that each voice context switch records in
> staff
> properties what the currently active voice is for both parts. E.g., if
> both parts are merged, staff property activeVoicePartOne and
> activeVoicePartTwo both get set to "shared". Likewise, if stemming is
> split, the activeVoicePartOne gets set to "one", and activeVoicePartTwo
> gets set to "two", and so on. The staff on which \partcombine operates
> should be named.
>
> The next step is to modify new-lyric-combine-music-iterator by changing
> find_voice(). The semantics here are modified so that failure to find
> the named voice context (from \lyricsto) results in a search for the
> named staff context. If the named staff context is found, then
> find_voice() will subsequently look up the activeVoicePartOne or
> activeVoicePartTwo property to find which voice should be set next.
>
> The input file would look something like this:
>
> \score {
> <<
> \context Staff = "treble" {
> \partcombine \soprano \alto
> }
> \lyricsto "treble.1" \new Lyrics \verseOne
> \lyricsto "treble.1" \new Lyrics \verseTwo
> \new Staff {
> \partcombine \tenor \bass
> }
> }
>
> This will set lyrics to the "soprano" voice, while specifying "treble.2"
> would set lyrics to the alto voice.
> I'm by no means suggesting that this is an efficient solution (I rather
> doubt it),
It's not so bad actually. How about sending a patch to the list?
> but I'm still trying to figure out the structures and
> interfaces between C++ and Scheme without breaking existing
> functionality. (For hymn-writing purposes, I've also had to tweak some
> other aspects of \partcombine, for example, unisons should have two
> stems while unison rests should usually be merged, and the chord
> interval was expanded to a twelfth rather than just an octave.)
The music functions (ly/music-functions-init.ly) get the parser as an
argument, which should be used to extract variables for tuning the
behavior of the part-combiner. Those can be used for merging
> Does anyone have any comments or ideas for better approaches? I'm
> particularly concerned about tossing in a named staff instead of a named
> voice for \lyricsto. Is there a better way to specify this
> syntactically?
No, I guess not.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
