Re: implementation plan for music streams

[Erik Sandberg]

On Thursday 11 May 2006 00:54, Han-Wen Nienhuys wrote:
> 2006/5/10, Erik Sandberg <address@hidden>:
> > Citerar Han-Wen Nienhuys <address@hidden>:
> > > > Known issue: unfold-repeats will probably not work for percent
> > > I don't understand this. unfold-repeats is on the front end, we can
> > > just make it replace PercentRepeatMusic with UnfoldedRepeatMusic
> > > wholly; that should work, right?
> >
> > I implemented percent repeats in a way similar to tuplet brackets, i.e.
> > by sending a parallel event. One reason for this decision is that the
> > EventChord
> > iterator is where events are supposed to be reported.
>
> Yes, and that's what I disagree with. I agree you need to put in events for
> signaling information, but I oppose to inserting them in the parser. Can
> you change the code to make the iterators generate those events on the fly.

Hm, I guess the easiest/cleanest way would be to let the 
percent-repeat-iterator create an implicit SequentialMusic around the music, 
with the additional percent elements, and then to let process_music pretend 
that this SequentialMusic expression is its 'element. That way, all 
timekeeping can be outsourced to the Sequential_music_iterator, and the 
percent-repeat-iterator can more-or-less be reduced to an override of 
construct_children.

I also have two slightly related questions:
- In the best of worlds, should all events always be reported to bottom 
contexts? I see no technical reasons why it would need to be that way, but 
it's a nice convention and it requires little work.
- If answer is yes, then I'd like to suggest that Music_iterator::try_music 
automatically should descend the iterator to a bottom context. That would 
eliminate the parser's need to wrap expressions inside \context Bottom. I can 
implement this when I've finished some more of the music stream refactorings.

> > > I don't understand. Why don't you send TupletSpanEvents (START, STOP)
> > >
> > > from the iterator? If you do that, you might even be able to scrap a
> > > lot of the hairy timekeeping logic in the engraver.
> >
> > The nice thing about my solution is that time-scaled-music-iterator can
> > be scrapped altogether. This could also be achieved with start/stop
> > events by expanding \times <mus> to
> > { TupletSpanStartEvent <mus> TupletSpanStopEvent }
> > but I guess there would be problems with nested tuplets (how to pair
> > START and
> > STOP events?)
>
> start and stop events are nested, just like parentheses. A stop stops the
> most recently started one.

ok, fair enough. Then would it be OK to let \times expand to a SequentialMusic 
and drop the iterator, as I suggested? (I think there are essential 
differences between this case and percent repeats, as the required 
time-keeping in the iterator would be roughly equivalent to the current 
time-keeping in Tuplet_engraver)

I'm also considering to change the engraver's tuplets_ member to a list or 
stack, instead of vector.

-- 
Erik