On Apr 26, 2015, at 13:11 , Keith OHara <k-ohara5...@oco.net> wrote:
>
> On Sun, 26 Apr 2015 05:37:14 -0700, Dan Eble <d...@faithful.be> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
