Re: [partcombine] honouring Voice context name

[Kieren MacMillan]

Hi Dan,

> The part combiner can also route events to “shared”, “solo”, and “null” 
> contexts.  If you took the step you’re proposing, the next question would be 
> why can’t a person control those other names too?  If there is going to be 
> user control, should it be more comprehensive?

Absolutely.

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 it should be more comprehensive, the next question is will it scale if 
> someone finally buckles down and makes the part combiner work with more than 
> two parts?

An excellent question. I would love to be that [swash]buckler, but given the 
combinatorial growth rate of the possible multi-voice interactions, I currently 
don't have an inkling how to scale the partcombiner to *three* voices, let 
alone "arbitrary". I'm hoping tackling and perfecting [sic] the two-voice 
version will give me better insights in that direction.

> On the contrary, your suggestion seems aesthetic.  Whether the up-stem voice 
> is “one” or “fred” does not impact the algorithm.  You'd still have one part 
> jumping around between “fred”, “shared”, and “solo”.

See above; I'm hoping the voice names *will* impact the algorithm (in a 
positive sense).

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

> Getting back to your idea: the state machine definition has voice names, so 
> if you wanted to make the voice names flexible, I suppose you would either
> 1) use the existing state machine as a template: make a copy, replace the 
> names, pass it on to the part combiner; OR 
> 2) give the part combiner a map from the state-machine voice names to the 
> user's voice names
> 
> I’m not a good judge of which is more lispy.  (1) strikes me as more 
> complicated but probably better performing.

I'll try (1), unless I hear or find something that suggests I should do 
otherwise.

Thanks!
Kieren.

________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: address@hidden