[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: applyOutput Lyrics.LyricText not working?
From: |
David Kastrup |
Subject: |
Re: applyOutput Lyrics.LyricText not working? |
Date: |
Sun, 03 Jul 2016 09:29:30 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
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