[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reimplement forced partcombine decisions via context properties (iss
From: |
dak |
Subject: |
Re: Reimplement forced partcombine decisions via context properties (issue 144600043 by address@hidden) |
Date: |
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
\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/