Erik Sandberg schreef:
4. As a first demo, arpeggio-engraver has been rewritten to use these mechanisms.
yes, see below.
B. Create a dummy listener that protects all incoming events, and unprotects them at the end of each moment. The easiest way is probably to let Score-level translators take care of this. This is the easiest and safest solution, but also the most inefficient one. C. Create some macro trickery in translators, so that incoming events are remembered and protected automatically between try_music and stop_translation_timestep.
go for either B or C. I'm not sure whether you can make B work, because it sounds as if there still might still be a small time unprotected time interval before the event reaches the protection engraver.
for protection, don't use event->protect() rather use a derived_mark() and a vector<Event*>
D. Add an 'event property to Music, so that sent events are protected by their music origins. This is the easiest solution, but I'm nervous about memory errors that can happen when a different front-end is used (e.g., when loading music streams directly from a file)
no, Music should not connect to stream events
-bool -Arpeggio_engraver::try_music (Music *m) +IMPLEMENT_TRANSLATOR_LISTENER (Arpeggio_engraver, hear_arpeggio, "ArpeggioEvent"); +void Arpeggio_engraver::hear_arpeggio (Stream_event *ev)
can you reengineer this to have less redundancy? I would expect that you can get enough info from
IMPLEMENT_TRANSLATOR_LISTENER (Arpeggio_engraver, arpeggio) -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
