On Thursday 11 May 2006 00:54, Han-Wen Nienhuys wrote:
> 2006/5/10, Erik Sandberg <[EMAIL PROTECTED]>:
> > Citerar Han-Wen Nienhuys <[EMAIL PROTECTED]>:
> > > > 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
