On Oct 28, 2014, at 03:00 , [email protected] 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
