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

[dak]

On 2014/10/28 12:35:08, dan_faithful.be wrote:
> On Oct 28, 2014, at 03:00 , mailto: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.

It sounds like an approach along those lines might make a better fit for
n->m partcombining with n>2.  But it would still need a lot of details
to figure out.

https://codereview.appspot.com/144600043/