On 2012/01/18 14:36:57, MikeSol wrote:
On 2012/01/18 14:27:53, dak wrote: > Are iterators allowed to change their input?
I'm not sure if they're allowed by design, but I know they're allowed
to
proliferate input that wasn't there before.
I don't know what you mean by "proliferate input" as this verb is intransitive. If you mean generating new input: sure. I am worried by it changing the input. If it gets iterated in a different context again, information will be gone.
One solution is to just set a property in the event
"ignore-articulations". Where would be the point? If I plan to touch up the stream event before broadcasting it, I can't use the everything-included report_event anyway. If I plan to touch up the music event in a manner equivalent to deleting the articulations, I can just delete the articulations instead. In either case, the original music event would behave differently after having once visited the iterator. So I guess I'll take your patch and just do a bit of copying of what report_event does. It is pretty much equivalent to my messing around with an additional optional boolean argument to report_event, but less hidden. Perhaps it would be cleanest to make report_event a virtual function? Then rhythmic_iterator could just override it. Better yet, EventChord could just override it, and we would not need the rhythmic iterator at all. http://codereview.appspot.com/5554048/ _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
