Re: Reimplement forced partcombine decisions via context properties (issue 144600043 by address@hidden)

[Dan Eble]

On Oct 28, 2014, at 03:00 , address@hidden wrote:
> 
> Now I see the problem.  The properties you are using are those created
> in a pre-engraving step, done separately on each of the inputs to
> \partcombine.  Using properties of those separate contexts for the
> force-part-combine state is a bad idea.

One thing just occurred to me.  (It feels like a bit of a non sequitur, but 
anyway…)  The part combiner has two input voices and three output voices.

There is more than one possible effect that a command like \partCombineApart 
could have.  It could place the top note in voice “one” and the bottom note in 
voice “two”; but what if someone wanted to separate the parts and leave the top 
note in voice “shared” and the bottom note in voice “two”, for example?

Years ago, I tried to submit a patch to allow setting the voice names for the 
part combiner so that this could be done uniformly for the whole input.  I 
failed to find a solution that was acceptable for inclusion (though it worked 
for me) but maybe mentioning it now will inspire some creative problem-solving.

It’s weird if \partCombineApart means no more than “separate the parts” 
regardless of the part it appears in.  But if it instead means, “route the 
current part to voice x instead of what you would normally do, and I’m not 
trying to tell you whether it’s more appropriate to put the other part in voice 
y or z”, I think that would be easier to comprehend.  I haven’t thought through 
it systematically though.
— 
Dan