https://codereview.appspot.com/44860045/diff/60001/Documentation/contributor/programming-work.itexi File Documentation/contributor/programming-work.itexi (right):
https://codereview.appspot.com/44860045/diff/60001/Documentation/contributor/programming-work.itexi#newcode43 Documentation/contributor/programming-work.itexi:43: event a moment (a time) and a context, which is the environment in which the No, events are not assigned a time. And neither are they assigned a context. Iteration interprets music expressions through "iterators". Most of the effects are subsequently produced through "stream events". Events are "broadcast" by iterators in a particular context at a given global time. This broadcast is received by event listeners, usually in the form of "translators" (in the printed output, "engravers") in the context or any parent context. The translators are responsible for initiating further processing. https://codereview.appspot.com/44860045/diff/60001/Documentation/contributor/programming-work.itexi#newcode1578 Documentation/contributor/programming-work.itexi:1578: @item @code{ok ()} returns whether there are any events left to send. I think that ok () is only relevant when the iterator is of the run_always kind. If it isn't, pending_mom () gives the next time of call. Don't consider this authoritive: that's more or less what I tried figuring out from the code and remember right now without actually cross-checking. But it might help you get a better idea of what to write here actually after checking the code again. https://codereview.appspot.com/44860045/diff/60001/input/regression/initial-contexts.ly File input/regression/initial-contexts.ly (right): https://codereview.appspot.com/44860045/diff/60001/input/regression/initial-contexts.ly#newcode10 input/regression/initial-contexts.ly:10: %%and iteration can't skip time without it. This comment is a bit of a non-sequitur: time is kept in the Global context, so it could get skipped. I am not actually sure how SkipEvent even works. https://codereview.appspot.com/44860045/diff/60001/lily/global-context.cc File lily/global-context.cc (right): https://codereview.appspot.com/44860045/diff/60001/lily/global-context.cc#newcode135 lily/global-context.cc:135: //Maybe they should be called directly rather than through events. If you called them directly, the EventListener framework used for quoting and part combining would stop working. https://codereview.appspot.com/44860045/diff/60001/lily/global-context.cc#newcode148 lily/global-context.cc:148: find_create_context (default_child_, "", SCM_EOL); This precludes \new Score \with ..., quite a no-no. https://codereview.appspot.com/44860045/diff/60001/lily/translator-group.cc File lily/translator-group.cc (right): https://codereview.appspot.com/44860045/diff/60001/lily/translator-group.cc#newcode232 lily/translator-group.cc:232: if (!new_context->now_mom ().main_part_.is_infinity ()) Don't understand that condition. https://codereview.appspot.com/44860045/diff/60001/lily/translator-group.cc#newcode235 lily/translator-group.cc:235: DOWN); Isn't that sufficient to have the Score context created in time? Without requiring the other fixes? https://codereview.appspot.com/44860045/diff/60001/ly/engraver-init.ly File ly/engraver-init.ly (right): https://codereview.appspot.com/44860045/diff/60001/ly/engraver-init.ly#newcode527 ly/engraver-init.ly:527: @code{\\score} or @code{\\layout} block) is processed." If a Score context would be created automatically when an output definition is processed, one _could_ not create it explicitly afterwards. These two sentences are contradictory. https://codereview.appspot.com/44860045/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
