|
From: | Han-Wen Nienhuys |
Subject: | Re: implementation plan for music streams |
Date: | Fri, 12 May 2006 10:34:16 +0200 |
User-agent: | Thunderbird 1.5 (X11/20060313) |
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 percentI 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
[Prev in Thread] | Current Thread | [Next in Thread] |