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. https://codereview.appspot.com/144600043/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
