Re: [partcombine] honouring Voice context name

[Dan Eble]

> On Jun 7, 2017, at 09:34, Kieren MacMillan <address@hidden> wrote:
> 
> As a first step, I would offer that we should figure out how (if?) the "one" 
> context can be funnelled seamlessly into the "shared" and "solo" contexts — 
> as I see it, that's the main problem with lyrics getting disconnected (etc.).

If we’re going to ask that kind of question, let’s mention a more radical 
redesign.

The context properties of a part, such as stem direction, need to change as the 
part’s relationship with other parts changes.  The current part combiner 
accomplishes this with a set of voices with fixed properties.  It slices the 
part into pieces and distributes them to the voice with the appropriate 
properties.

Could it not leave the parts where they are (continuous parts in exactly one 
voice context per part) and change their context properties instead?

>> If you do want to impact the algorithm, it is possible to define a music 
>> function that uses the deeper parts of the part combiner with your own state 
>> machine.  Variations I’ve tried:
>> 1) never enter solo mode
> 
> That doesn't sound quite right to me…
> 
>> 2) add force commands \partcombineRovingI and ~II and corresponding voices 
>> “rovingOne” and “rovingTwo” to support staff splitting (I hoped to 
>> contribute this, but I haven’t had time.)
> 
> I'll look at that. Thanks.

I’m not sure I was clear.  Those are examples of things I’ve actually 
accomplished using most of the scheme parts of the part combiner as shipped 
with Lilypond.  I was trying to point out that there is already more internal 
flexibility than meets the eye.  Depending on your use cases, you might already 
be able to take advantage of it.
— 
Dan