lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 4622: create a <Part-combiner> class (issue 265260043 by addre


From: dak
Subject: Re: Issue 4622: create a <Part-combiner> class (issue 265260043 by address@hidden)
Date: Sat, 03 Oct 2015 12:56:50 +0000

On 2015/10/03 12:42:19, Dan Eble wrote:
I've marked the ticket as "needs work" for now.  I still have
questions.  It
*would* be nice to be able to say

    \override Staff.partCombineParameter = #x
    \partcombine \one \two ...

and have the part combiner get its initial settings from the context.

You bet.

The
current implementation runs the combination algorithm as the
part-combine music
is constructed.  But there is a way to defer evaluating the elements
of music
until they are requested, isn't there?

elements-callback, but that's mostly for sequential-music.  But it is
mostly up to the iterator how it does things.  The partcombine-iterator
currently combines a split-list with the running stuff to get things.
The disadvantage of on-the-fly operation might be that creating the
split-list might be expensive so reusing the not-yet-partcombined music
might get slower.

Would it be safe to run the combination
algorithm from a callback that is not called until the part-combine
music is
able to look up its initial parameters in context?

I think so.  For better or worse, the split list generator runs in a
sandbox independent from the original contexts, so if you want to see
the part combining properties in their original, you'd have to pick them
off and transfer them over.  However, the stream events generated for
set, unset, and once set, once unset, no longer contain any reference to
actual context data so it does not really matter all that much whether
the "real" context properties are out of whack with the "virtual" ones
for the purpose of the split list generator.

I'm not very clear on the
sequencing of things; I would worry that the elements might be needed
earlier
than that, or that there might be a lot of recalculating, etc.

I think the recalculation is the principal worry but it should be quite
faster than any actual typesetting of the resulting material.

https://codereview.appspot.com/265260043/



reply via email to

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