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