Reimplement forced partcombine decisions via context properties

Reimplement forced partcombine decisions via context properties

One music type and concept less to worry about.


Also contains commits:

Remove definitions of \partcombine*Once

They are now called as \once \partcombine*


Run scripts/auxiliar/update-with-convert-ly.sh


convert-ly rule "partcombine*Once -> \once \partcombine*"

[dak, 2014-09-25 15:59:50]

Oops, forgot \once \partcombineAutomatic

[dak, 2014-09-28 21:59:51]

numerous fixes and changes, track forced state in voices separately

[Keith, 2014-10-28 07:00:33]

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.

Right now, \partCombineApartOnce, etc., affects the split-list output of the
music function \partcombine
 \displayMusic \partcombine
  {\partcombineApart
   e4 e e \partcombineApartOnce e | e e e e}
  {c4 c \partcombineChords c c     | c c c c } }
so it makes sense to store the state in a variable in the scheme that implements
\partcombine as it is done now.

In order to make a \once\partcombineApart work like most other \once\override
commands, you would have to do something like delay the forced part-combine
decisions until the real engraving, write a real Part_combine_engraver that
lives in the Staff, and store the forced state in properties in that Staff
(maybe renaming what is currently called Part_combine_engraver to
Part_combine_text_engraver).

https://codereview.appspot.com/144600043/diff/40001/scm/part-combiner.scm
File scm/part-combiner.scm (right):

https://codereview.appspot.com/144600043/diff/40001/scm/part-combiner.scm#new...
scm/part-combiner.scm:262: (evs1 (recording-group-emulate m1 listener)))
So each of the two music expressions going into \partcombine is sent through a
scheme engraver, with an output definition 'partCombineLister' that turns of
graphical layout, to generate events for \partcombine to analyze and turn into a
music expression to go into the usual engravers.

It seems that the contexts created for these two engraving processes are the
only ones available for you to set properties that affect the part-combining
state in the music-expression output of \partcombine. But there are two separate
iterations separately keeping track of properties, while we want the
forced-part-combine commands to affect the single combining function.

Unless you want add a third iterator call, and send a parallel music constructin
of m1 and m2 into that, for the forced-part-combine commands, handling the
commands as properties at this stage is awkward and cannot give as nice a
behavior as Reinhold's original code.

[dak, 2014-10-28 07:58:28]

On 2014/10/28 07:00:33, Keith wrote:

> In order to make a \once\partcombineApart work like most other \once\override
> commands, you would have to do something like delay the forced part-combine
> decisions until the real engraving, write a real Part_combine_engraver that
> lives in the Staff, and store the forced state in properties in that Staff
> (maybe renaming what is currently called Part_combine_engraver to
> Part_combine_text_engraver).

I don't like the design of the current partcombiner.  In particular it seems
strange to use an artificial output definition rather than one derived from the
current one.  But that's a larger and separate issue.

> Unless you want add a third iterator call, and send a parallel music
constructin
> of m1 and m2 into that, for the forced-part-combine commands, handling the
> commands as properties at this stage is awkward and cannot give as nice a
> behavior as Reinhold's original code.

For some definition of "nice".

At any rate, things would be considerably more straightforward if one caught the
after-timestep actions of \once ... separately in a music list instead of
grouping them with the next event.  But that would mean changing the output of
recording-group-emulate or what it's called.

[dan_faithful.be, 2014-10-28 12:35:08]

On Oct 28, 2014, at 03:00 , k-ohara5a5a@oco.net 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

[dak, 2014-10-28 18:09:11]

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

[dak, 2015-09-26 07:52:20]

Reimplement after issue 4609 makes this possible

[dak, 2015-09-29 18:05:50]

Rebase convert-ly rules