Re: implementation plan for music streams

[Han-Wen Nienhuys]

Erik Sandberg schreef:
> 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 think you can just use Sequential_iterator for that, which you give a 
SCM list of elements. It will also do the Right Thing if there is a 
grace note involved.

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

Yes, sensible idea in the context of eventifying everything


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

Just use a vector, with push_back and pop_back (?). There's no point in 
a making it different data structure, and it confuses other programmers, 
as it would be the only STL list in the program.

--

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

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com