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

[k-ohara5a5a]

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

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