lilypond-devel
[Top][All Lists]
Advanced

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

Re: \change Voice


From: Keith OHara
Subject: Re: \change Voice
Date: Sun, 26 Apr 2015 10:11:28 -0700
User-agent: Opera Mail/12.16 (Win32)

On Sun, 26 Apr 2015 05:37:14 -0700, Dan Eble <address@hidden> 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.




reply via email to

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