[Top][All Lists]

[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
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
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]