Thomas Morley <thomasmorle...@gmail.com> writes: > 2016-07-03 0:19 GMT+02:00 David Kastrup <d...@gnu.org>: >> >> Two possible ways to fix this: >> >> 1) add the Output_property_engraver on all possibly interesting >> Bottom(?) contexts >> 2) Move the Output_property_engraver to Score level only and change it >> so that it sends the respective grob starting from the originating >> engraver context to the first (all?) context in the parentage of that >> context that matches the alias. >> >> The second solution is more work but also more likely to work as >> expected without further thinking. > > Thanks for the hints, I'll have to test how it will work... > > What's the reason Output_property_engraver is not added more or less > everywhere?
Efficiency? Oversight? We had a similar situation with the Tweak_engraver at some point of time, before commit 77d99c047772da8e897af75c49b00523556da01e Author: David Kastrup <d...@gnu.org> Date: Thu Apr 4 11:12:38 2013 +0200 Issue 3296: Move Tweak_engraver to Score level This makes it possible to tweak items announced at Score level, like MetronomeMark and RehearsalMark. The advantage is that tweaks will be applied once regardless of the context structure (the Score context should exist only once). Due to the hierarchical nature of acknowledgers, acknowledgers in lower contexts will now get to see the grobs before tweaks have been applied. However, grobs are still unfinished (except for type, properties initialized via context properties and cause) at the time they are announced, with other details only getting filled in by the engraver after announcement, so the potential for trouble seems low. Acknowledgers should usually just register a grob (or write grob data) with any actual reading of grob data occurring at the end of the timestep instead. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user