Re: applyOutput Lyrics.LyricText not working?

[David Kastrup]

David Kastrup <address@hidden> writes:

> Thomas Morley <address@hidden> writes:
>
>> 2016-07-03 0:19 GMT+02:00 David Kastrup <address@hidden>:
>>>
>>> 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 <address@hidden>
> 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.

Ok,

Tracker issue: 4914 (https://sourceforge.net/p/testlilyissues/issues/4914/)
Rietveld issue: 303960043 (https://codereview.appspot.com/303960043)
Issue description:
  Move Output_property_engraver to Score level  Due to the
  hierarchical nature of acknowledgers, acknowledgers in lower
  contexts will now get to see the grobs before applyOutput has done
  its work.  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 or in the process-acknowledged phase.   Also
  contains commits:  Add Output_property_engraver back to Score   Run
  scripts/auxiliar/update-with-convert-ly.sh   convert-ly rule for
  removing Output_property_engraver  It's highly unlikely that users
  will redefine the Score context from scratch, so the convert-ly rule
  just removes every occurence of Output_property_engraver from user
  source.  Obviously, when running the rule on the LilyPond code base,
  we will need to fix up the Score engraver manually to retain the
  Output_property_engraver .

Haven't run "make check" for it since my disk currently is too full for
the 4GB or more this will take.

-- 
David Kastrup