Contexts affected by \override and \overrideProperty

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Contexts affected by \override and \overrideProperty

Urs Liska-3

Can someone explain to me why \overrideProperty Staff.BarLine.color #red colors the barlines in *all* staves while \override Staff.BarLine.color = #red only affects the current Staff context?

I have just re-read http://lilypond.org/doc/v2.19/Documentation/notation/set-versus-override and am scratching my head. I do claim to have some experience by now but this page isn't actually really helpful:

"The commands ... \overrideProperty change grob properties by bypassing all context properties completely and, instead, catch grobs as they are being created, setting properties on them ... for a specific override."

This doesn't give a clue when \overrideProperty should (or must) be used instead of \override or what the difference in behaviour actually is.

\overrideProperty is also present on http://lilypond.org/doc/v2.19/Documentation/notation/available-music-functions#index-overrideProperty-1

overrideProperty [music] - grob-property-path (list of indexes or symbols) value (any type)
Set the grob property specified by grob-property-path to value. grob-property-path is a symbol list of the form Context.GrobName.property or GrobName.property, possibly with subproperties given as well.

As opposed to \override which overrides the context-dependent defaults with which a grob is created, this command uses Output_property_engraver at the grob acknowledge stage. This may be necessary for overriding values set after the initial grob creation.

This gives an indication for why it may in some cases be necessary to use \overrideProperty but it doesn't explain why it seems to affect objects in all contexts instead of just the one where it is used.

I'd be glad about any clarification, for reference: this relates to this issue: https://github.com/openlilylib/stylesheets/issues/5

Best
Urs


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
dak
Reply | Threaded
Open this post in threaded view
|

Re: Contexts affected by \override and \overrideProperty

dak
Urs Liska <[hidden email]> writes:

> Can someone explain to me why \overrideProperty Staff.BarLine.color
> #red colors the barlines in *all* staves while \override
> Staff.BarLine.color = #red only affects the current Staff context?
>
> I have just re-read
> http://lilypond.org/doc/v2.19/Documentation/notation/set-versus-override
> and am scratching my head. I do claim to have some experience by now
> but this page isn't actually really helpful:
>
>    "The commands ... |\overrideProperty| change grob properties by
>    bypassing all context properties completely and, instead, catch
>    grobs as they are being created, setting properties on them ... for
>    a specific override."
>
> This doesn't give a clue when \overrideProperty should (or must) be
> used instead of \override or what the difference in behaviour actually
> is.
>
> \overrideProperty is also present on
> http://lilypond.org/doc/v2.19/Documentation/notation/available-music-functions#index-overrideProperty-1
>
>    |overrideProperty| [music] - grob-property-path (list of indexes or
>    symbols) value (any type)
>        Set the grob property specified by grob-property-path to value.
>        grob-property-path is a symbol list of the form
>        |Context.GrobName.property| or |GrobName.property|, possibly
>        with subproperties given as well.
>
>        As opposed to |\override| which overrides the context-dependent
>        defaults with which a grob is created, this command uses
>        |Output_property_engraver| at the grob acknowledge stage. This
>        may be necessary for overriding values set after the initial
>        grob creation.
>
> This gives an indication for why it may in some cases be necessary to
> use \overrideProperty but it doesn't explain why it seems to affect
> objects in all contexts instead of just the one where it is used.

Because the respective engraver is only active at Score level and
overrides the properties in _all_ contexts of the given type.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Contexts affected by \override and \overrideProperty

Urs Liska-3

Am 18.02.19 um 17:30 schrieb David Kastrup:

> Urs Liska <[hidden email]> writes:
>
>> Can someone explain to me why \overrideProperty Staff.BarLine.color
>> #red colors the barlines in *all* staves while \override
>> Staff.BarLine.color = #red only affects the current Staff context?
>>
>> I have just re-read
>> http://lilypond.org/doc/v2.19/Documentation/notation/set-versus-override
>> and am scratching my head. I do claim to have some experience by now
>> but this page isn't actually really helpful:
>>
>>     "The commands ... |\overrideProperty| change grob properties by
>>     bypassing all context properties completely and, instead, catch
>>     grobs as they are being created, setting properties on them ... for
>>     a specific override."
>>
>> This doesn't give a clue when \overrideProperty should (or must) be
>> used instead of \override or what the difference in behaviour actually
>> is.
>>
>> \overrideProperty is also present on
>> http://lilypond.org/doc/v2.19/Documentation/notation/available-music-functions#index-overrideProperty-1
>>
>>     |overrideProperty| [music] - grob-property-path (list of indexes or
>>     symbols) value (any type)
>>         Set the grob property specified by grob-property-path to value.
>>         grob-property-path is a symbol list of the form
>>         |Context.GrobName.property| or |GrobName.property|, possibly
>>         with subproperties given as well.
>>
>>         As opposed to |\override| which overrides the context-dependent
>>         defaults with which a grob is created, this command uses
>>         |Output_property_engraver| at the grob acknowledge stage. This
>>         may be necessary for overriding values set after the initial
>>         grob creation.
>>
>> This gives an indication for why it may in some cases be necessary to
>> use \overrideProperty but it doesn't explain why it seems to affect
>> objects in all contexts instead of just the one where it is used.
> Because the respective engraver is only active at Score level and
> overrides the properties in _all_ contexts of the given type.


So this means that if I'm in the situation where I'm forced to use
\overrideProperty this property will always be overridden on the Score
context?

I will probably have to dig pretty deep into my library's code to find
out if I can change that to a \once \override or a \tweak. I don't
recall exactly why but when I last worked on the code I came to the
conclusion that it was the necessary and only possible approach.

Urs


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Contexts affected by \override and \overrideProperty

Urs Liska-3


Am 19.02.19 um 12:14 schrieb Urs Liska:
\overrideProperty is also present on
http://lilypond.org/doc/v2.19/Documentation/notation/available-music-functions#index-overrideProperty-1

    |overrideProperty| [music] - grob-property-path (list of indexes or
    symbols) value (any type)
        Set the grob property specified by grob-property-path to value.
        grob-property-path is a symbol list of the form
        |Context.GrobName.property| or |GrobName.property|, possibly
        with subproperties given as well.

        As opposed to |\override| which overrides the context-dependent
        defaults with which a grob is created, this command uses
        |Output_property_engraver| at the grob acknowledge stage. This
        may be necessary for overriding values set after the initial
        grob creation.

This gives an indication for why it may in some cases be necessary to
use \overrideProperty but it doesn't explain why it seems to affect
objects in all contexts instead of just the one where it is used.
Because the respective engraver is only active at Score level and
overrides the properties in _all_ contexts of the given type.


So this means that if I'm in the situation where I'm forced to use \overrideProperty this property will always be overridden on the Score context?

I will probably have to dig pretty deep into my library's code to find out if I can change that to a \once \override or a \tweak. I don't recall exactly why but when I last worked on the code I came to the conclusion that it was the necessary and only possible approach.

Urs


Just to make sure: am I right to think that it is not "safe" to move the Output_property_engraver to lower level contexts, particularly within a library file that has no knowledge of what the end-user is actually doing?

\layout {
  \context {
    \Score
    \remove Output_property_engraver
  }
  \context {
    \Staff
    \consists Output_property_engraver
  }
}

works fine - in the MWE ...

Urs


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
dak
Reply | Threaded
Open this post in threaded view
|

Re: Contexts affected by \override and \overrideProperty

dak
In reply to this post by Urs Liska-3
Urs Liska <[hidden email]> writes:

> Am 18.02.19 um 17:30 schrieb David Kastrup:
>> Urs Liska <[hidden email]> writes:
>>
>>> Can someone explain to me why \overrideProperty Staff.BarLine.color
>>> #red colors the barlines in *all* staves while \override
>>> Staff.BarLine.color = #red only affects the current Staff context?
>>>
>>> I have just re-read
>>> http://lilypond.org/doc/v2.19/Documentation/notation/set-versus-override
>>> and am scratching my head. I do claim to have some experience by now
>>> but this page isn't actually really helpful:
>>>
>>>     "The commands ... |\overrideProperty| change grob properties by
>>>     bypassing all context properties completely and, instead, catch
>>>     grobs as they are being created, setting properties on them ... for
>>>     a specific override."
>>>
>>> This doesn't give a clue when \overrideProperty should (or must) be
>>> used instead of \override or what the difference in behaviour actually
>>> is.
>>>
>>> \overrideProperty is also present on
>>> http://lilypond.org/doc/v2.19/Documentation/notation/available-music-functions#index-overrideProperty-1
>>>
>>>     |overrideProperty| [music] - grob-property-path (list of indexes or
>>>     symbols) value (any type)
>>>         Set the grob property specified by grob-property-path to value.
>>>         grob-property-path is a symbol list of the form
>>>         |Context.GrobName.property| or |GrobName.property|, possibly
>>>         with subproperties given as well.
>>>
>>>         As opposed to |\override| which overrides the context-dependent
>>>         defaults with which a grob is created, this command uses
>>>         |Output_property_engraver| at the grob acknowledge stage. This
>>>         may be necessary for overriding values set after the initial
>>>         grob creation.
>>>
>>> This gives an indication for why it may in some cases be necessary to
>>> use \overrideProperty but it doesn't explain why it seems to affect
>>> objects in all contexts instead of just the one where it is used.
>> Because the respective engraver is only active at Score level and
>> overrides the properties in _all_ contexts of the given type.
>
>
> So this means that if I'm in the situation where I'm forced to use
> \overrideProperty this property will always be overridden on the Score
> context?

No, just in all Staff contexts (if Staff is what you specified).  The
Score context property will remain unchanged.

This does not sound overly useful, does it?

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Contexts affected by \override and \overrideProperty

Urs Liska-3

Am 19.02.19 um 12:27 schrieb David Kastrup:

> Urs Liska <[hidden email]> writes:
>
>> Am 18.02.19 um 17:30 schrieb David Kastrup:
>>> Urs Liska <[hidden email]> writes:
>>>
>>>> Can someone explain to me why \overrideProperty Staff.BarLine.color
>>>> #red colors the barlines in *all* staves while \override
>>>> Staff.BarLine.color = #red only affects the current Staff context?
>>>>
>>>> I have just re-read
>>>> http://lilypond.org/doc/v2.19/Documentation/notation/set-versus-override
>>>> and am scratching my head. I do claim to have some experience by now
>>>> but this page isn't actually really helpful:
>>>>
>>>>      "The commands ... |\overrideProperty| change grob properties by
>>>>      bypassing all context properties completely and, instead, catch
>>>>      grobs as they are being created, setting properties on them ... for
>>>>      a specific override."
>>>>
>>>> This doesn't give a clue when \overrideProperty should (or must) be
>>>> used instead of \override or what the difference in behaviour actually
>>>> is.
>>>>
>>>> \overrideProperty is also present on
>>>> http://lilypond.org/doc/v2.19/Documentation/notation/available-music-functions#index-overrideProperty-1
>>>>
>>>>      |overrideProperty| [music] - grob-property-path (list of indexes or
>>>>      symbols) value (any type)
>>>>          Set the grob property specified by grob-property-path to value.
>>>>          grob-property-path is a symbol list of the form
>>>>          |Context.GrobName.property| or |GrobName.property|, possibly
>>>>          with subproperties given as well.
>>>>
>>>>          As opposed to |\override| which overrides the context-dependent
>>>>          defaults with which a grob is created, this command uses
>>>>          |Output_property_engraver| at the grob acknowledge stage. This
>>>>          may be necessary for overriding values set after the initial
>>>>          grob creation.
>>>>
>>>> This gives an indication for why it may in some cases be necessary to
>>>> use \overrideProperty but it doesn't explain why it seems to affect
>>>> objects in all contexts instead of just the one where it is used.
>>> Because the respective engraver is only active at Score level and
>>> overrides the properties in _all_ contexts of the given type.
>>
>> So this means that if I'm in the situation where I'm forced to use
>> \overrideProperty this property will always be overridden on the Score
>> context?
> No, just in all Staff contexts (if Staff is what you specified).  The
> Score context property will remain unchanged.
>
> This does not sound overly useful, does it?


It *does* sound useful, just not for the problem at hand. I'm dealing
with annotating music, and I would often have loved to have the
possibility to "clone" one annotation through all related contexst (e.g.
the given example of a barline. If I annotate that the source used a
double barline that I corrected to a single one I will often want to
have it visible on all staves.)
This is currently the behaviour for the non-rhythmic music events but
not for others.

Knowing this it seems I have to find a way to avoide using
\overrideProperty somewhere in my engraver, which seems somewhat
daunting at this point. OTOH it may open up a way to *selectively* use
this behaviour for *all* music types.

Urs


>

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
dak
Reply | Threaded
Open this post in threaded view
|

Re: Contexts affected by \override and \overrideProperty

dak
Urs Liska <[hidden email]> writes:

> Am 19.02.19 um 12:27 schrieb David Kastrup:
>> Urs Liska <[hidden email]> writes:
>>
>>> Am 18.02.19 um 17:30 schrieb David Kastrup:
>>>> Urs Liska <[hidden email]> writes:
>>>>
>>>>> Can someone explain to me why \overrideProperty Staff.BarLine.color
>>>>> #red colors the barlines in *all* staves while \override
>>>>> Staff.BarLine.color = #red only affects the current Staff context?
>>>>>
>>>>> I have just re-read
>>>>> http://lilypond.org/doc/v2.19/Documentation/notation/set-versus-override
>>>>> and am scratching my head. I do claim to have some experience by now
>>>>> but this page isn't actually really helpful:
>>>>>
>>>>>      "The commands ... |\overrideProperty| change grob properties by
>>>>>      bypassing all context properties completely and, instead, catch
>>>>>      grobs as they are being created, setting properties on them ... for
>>>>>      a specific override."
>>>>>
>>>>> This doesn't give a clue when \overrideProperty should (or must) be
>>>>> used instead of \override or what the difference in behaviour actually
>>>>> is.
>>>>>
>>>>> \overrideProperty is also present on
>>>>> http://lilypond.org/doc/v2.19/Documentation/notation/available-music-functions#index-overrideProperty-1
>>>>>
>>>>>      |overrideProperty| [music] - grob-property-path (list of indexes or
>>>>>      symbols) value (any type)
>>>>>          Set the grob property specified by grob-property-path to value.
>>>>>          grob-property-path is a symbol list of the form
>>>>>          |Context.GrobName.property| or |GrobName.property|, possibly
>>>>>          with subproperties given as well.
>>>>>
>>>>>          As opposed to |\override| which overrides the context-dependent
>>>>>          defaults with which a grob is created, this command uses
>>>>>          |Output_property_engraver| at the grob acknowledge stage. This
>>>>>          may be necessary for overriding values set after the initial
>>>>>          grob creation.
>>>>>
>>>>> This gives an indication for why it may in some cases be necessary to
>>>>> use \overrideProperty but it doesn't explain why it seems to affect
>>>>> objects in all contexts instead of just the one where it is used.
>>>> Because the respective engraver is only active at Score level and
>>>> overrides the properties in _all_ contexts of the given type.
>>>
>>> So this means that if I'm in the situation where I'm forced to use
>>> \overrideProperty this property will always be overridden on the Score
>>> context?
>> No, just in all Staff contexts (if Staff is what you specified).  The
>> Score context property will remain unchanged.
>>
>> This does not sound overly useful, does it?
>
>
> It *does* sound useful, just not for the problem at hand.

Looks like a consequence of
commit 1d1976cb7da1d4625357e59a34837b1d46cac70c
Author: David Kastrup <[hidden email]>
Date:   Sun Jul 3 01:37:15 2016 +0200

    Issue 4914/1: Move Output_property_engraver to Score level
   
    This has the advantage of needing only one instantiation of the engraver
    and not having \applyOutput mysteriously refrain from having an effect
    in contexts without Output_property_engraver .
   
    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.

I think that this likely was not thought through.  It's a 2.19.46 change
so it looks like something that needs fixing before 2.20.

Apologies.

> Knowing this it seems I have to find a way to avoide using
> \overrideProperty somewhere in my engraver, which seems somewhat
> daunting at this point. OTOH it may open up a way to *selectively* use
> this behaviour for *all* music types.

Don't do this.  If you want something to apply Score-wide, use a Score
qualifier and work from there.  Consider the current behavior a bug.
I'll try coming up with a good fix within the day.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
dak
Reply | Threaded
Open this post in threaded view
|

Re: Contexts affected by \override and \overrideProperty

dak
In reply to this post by dak
David Kastrup <[hidden email]> writes:

> Urs Liska <[hidden email]> writes:
>
>> Can someone explain to me why \overrideProperty Staff.BarLine.color
>> #red colors the barlines in *all* staves while \override
>> Staff.BarLine.color = #red only affects the current Staff context?
>
> Because the respective engraver is only active at Score level and
> overrides the properties in _all_ contexts of the given type.

Ok, things are more complicated than that.  The respective events are
listened in at Score level.  When a grob is acknowledged, it is
acknowledged in all contexts of the right type in suitable relation to
the source engraver of the grob.  The end result is independent from
whatever context was current at the time the apply-output-event was
generated.

Making it dependent requires either having the Output_property_engraver
at all levels (as it had been before) which makes the current context be
reflected in just which of the various engravers is getting called, or
some support by the respective iterator (which does have a notion of
current context).

I lean towards calling the entire redesign a "thinko".  Unfortunately,
there have been significant irreversible convert-ly rules involved.  So
I need to figure out how to go from here.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user