On Sun, 26 Apr 2015 05:37:14 -0700, Dan Eble <d...@faithful.be> wrote:
I think \context...{} segments make a better implementation of \partcombine
than re-routing outlets in the part-combine-iterator.cc
I believe that would work, but it looks less tidy than keeping the original
part intact and wrapping it in a context which moves between Voice contexts.
... c4 } \context Voice = "one" { d4 ...
is only slightly less tidy than
... c4 \change Voice = "one" d4 ...
If you were thinking of a separate sequence of {... s1 \change Voice = "one"
s2...} in parallel with the part, then the \change method could be more tidy.
The wrapping context, though, means that we have to explicitly specify Voice in
any overrides that should carry through to the combined part
\partcombine { c'4 d'4 } {\slurDashed g'4( b') }
\partcombine { c'4 d'4 } {\override Voice.Slur.dash-definition = #'((0 1 0.4
0.75)) g'4( b') }
If your wrapping context is not aliased to Bottom, maybe you could convert-ly
to specify the Bottom context
\override Bottom.Slur.dash-definition = #'((0 1 0.4 0.75))
My guess is that the wrapping context will cause mysterious behavior that
outweighs its tidiness.
It would definitely be a challenge to reconstruct the part for
\displayLilyMusic; I’d probably stash the original parts in a property just for
that purpose, which seems like a dumb idea.
Don't reconstruct the input if you can show the output.
If \partcombine produces a music expression with context changes, rather than
structures like 'split-list, then we would want \displayLilyMusic to show the
result of \partcombine, not try to guess the input.
The documented purpose of \displayLilyMusic is to show the result of music
function, displayed in LilyPond input syntax.
\displayLilyMusic \relative c' {c4 e g c e g c e g c e g }
\displayLilyMusic \transpose c bes {c4 e g c }
\displayLilyMusic \appendToTag#'t d' { c'4 e' \tag#'t <<g'>> c' }
\displayLilyMusic \removeWithTag#'t << { c'4 e' g' c''} {c'4 \tag#'t e' g' c''}
>>
Only in cases where the music output from a function cannot be directly
expressed in Lilypond input syntax, does \displayLilyMusic try to guess the
function that produced the music. This reverse-engineering always seems a bit
silly, but producing valid LilyPond input for these cases means we can use
\displayLilyMusic more easily for its primary purpose.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
