Re: \change Voice

[Dan Eble]

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

Yes, that is exactly what I have been working on.  And I just realized 
(correctly, I hope) that having a wrapper context for \change to act upon is 
what makes this parallel structure possible.  If there existed a command to 
redirect the sequential iterator’s output to another Voice context without 
requiring a wrapper context, it could not function in a parallel sequence; the 
commands would have to be injected into the part sequence itself.  (That's not 
to say that it couldn’t be done.  Maybe that would even be easy, but I can't 
see that clearly yet.)

Aside: When used with partcombine, this wrapper is more like a musical voice 
than the Voice context is, which is unfortunate; however, that seems like a 
problem better solved later.

> 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.

Hmm.  What if there were a way to split the structural aspects of contexts from 
the property aspects?  Would a type of context that always defers property 
storage to its parent work around this problem?  Or slightly refined, a context 
that is passed over for *implicit* selection by a set/override.  Then one could 
still use \override Wrapper.Grob.property for debugging or whatever.

> 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.

Well, that simplifies the task a lot.  Thanks for all your feedback.
— 
Dan