[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reimplement forced partcombine decisions via context properties (iss
Re: Reimplement forced partcombine decisions via context properties (issue 144600043 by address@hidden)
Tue, 28 Oct 2014 07:58:28 +0000
On 2014/10/28 07:00:33, Keith wrote:
In order to make a \once\partcombineApart work like most other
commands, you would have to do something like delay the forced
decisions until the real engraving, write a real Part_combine_engraver
lives in the Staff, and store the forced state in properties in that
(maybe renaming what is currently called Part_combine_engraver to
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
of m1 and m2 into that, for the forced-part-combine commands, handling
commands as properties at this stage is awkward and cannot give as
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.