Re: How to customize iterator behavior?

[Han-Wen Nienhuys]

On Mon, Sep 13, 2010 at 11:50 AM, Reinhold Kainhofer
<address@hidden> wrote:
> I have a hard problem, which probably only someone with a lot of knowledge
> about the LilyPond internals can solve:
>
> I need to give the user the possibility to change the behavior of an interator
> by setting some property (or some other way, I don't care about the details).
> An example for this is the Lyric_combine_music_iterator, which checks for the
> context's associatedVoiceContext property.
>
> Now the problem is that when the iterator does it's job in the
> *_iterator::process function, the context properties for that moment have not
> been set yet. So, all calls to e.g. \set Lyrics.associatedVoiceContext = ...
> will take effect one moment too late.
> The docs note that this is known and "not a bug", which I would object too. It
> is a bug, we have just refused to fix it so far. A \set should always take
> effect immedately, not one time step later in some cases, while in others it
> takes effect immediately.

> I'm running into the same problem with the part-combiner.
>
> Can you think of any way to set a context property before the iterator's
> process method is called?

No.

How would that work?  Take moment to read the documentation of music
iterator in lily/include/music-iterator.hh.

The interface is very thin: the only action which can have a side
effect is the process() function, so, no you can set anything without
calling process().

The case for the part-combiner is actually feasible to solve: since
the part-combine-iterator first processes music to extract ordered
events (generating a so-called split list), you can disguise your
instructions as music events (which would be correctly timed into the
split-list).  You could then make the part-combine-iterator interpret
these events.

Arguably, the lyric combine iterator should also be rewritten to work
in this way, but I imagine it would be a hairy undertaking.

You are asking for a construct to influence how iterators work. It
would be tricky; imagine:

 \addlyrics {
   <<
     {  %% complex nesting
        c4

       \iterationHack

    }
  >>
 }
 \lyrics {
   blah blah
}

\iterationHack would be the construct that influences the iterator.
How would it signal which iterator it modifies?  The \iterationHack
would somehow have to signal that its interpretation needs to jump 3
nesting levels upwards.  I think this too deeply into the
implementation for anyone to safely use this.

> As I see it, we are currently missing a way to configure an interator. For
> contexts and engravers we have context properties, for grobs we have grob
> properties, but for iterators, there is no such thing...

The problem is that iterators are configured completely when they are
initialized, and they are unaware of their parents.  You are asking
for a construct that changes a parent long after it is initialized.


-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen