Re: „Anonymous” properties, deafening engravers and font features
Valentin Petzel writes: > Hello Jean, Hello Lukas, > > I’ve just remembered why I was asking for stoppable engravers: A while ago > there was a question about ties between different voices. Then someone (I > think it was you Lukas?) suggested moving the Engraver from the Voice context > to the Staff context. So then I thought that in such situations it would be > very useful to shortly deactivate the engraver for Voice and activate it of > Staff. > > I have extended \with-font-feature to also take lists of features and to > handle non string input (like a list of symbols). Also I have added a method > to remove features by prepending them by -, so -smcp removes a previous smcp > (which is not an uncommon way of handling this). > > What do you think about this? There is the more cumbersome way of inserting another context layer between Staff and Voice in the context hierarchy and have that carry the Slur_engraver . You can then change Voices temporarily into the same in-between context. Of course that is cumbersome, and when you also have similar requirements for occasionally attaching different voices to the same Stem or Beam or whatnot, this scheme does not scale. But it might work for some situations. -- David Kastrup
Re: „Anonymous” properties, deafening engravers and font features
Hello Jean, Hello Lukas,
I’ve just remembered why I was asking for stoppable engravers: A while ago
there was a question about ties between different voices. Then someone (I
think it was you Lukas?) suggested moving the Engraver from the Voice context
to the Staff context. So then I thought that in such situations it would be
very useful to shortly deactivate the engraver for Voice and activate it of
Staff.
I have extended \with-font-feature to also take lists of features and to
handle non string input (like a list of symbols). Also I have added a method
to remove features by prepending them by -, so -smcp removes a previous smcp
(which is not an uncommon way of handling this).
What do you think about this?
Cheers,
Valentin
Am Donnerstag, 18. November 2021, 22:21:14 CET schrieb Jean Abou Samra:
> Le 18/11/2021 à 21:51, Valentin Petzel a écrit :
> > Hello,
>
> > I have three ideas for maybe useful features for Lilypond:
> Let's keep this one here, but next time it would be
> a good idea to send feature requests to -devel instead.
> Not all developers read -user.
>
> > First, Lilypond is very strict about what values grob/context properties
> > can take. While this is generally a good thing it can be hindering, as
> > properties are more or less hard coded. So I suggest that maybe we could
> > have some sort of identifier for „custom” properties that skip the type
> > check. This would be useful for extended scripting where we want to store
> > arbitrary information.
> >
> > For example we might have Staves that should behave differently if certain
> > other Staves are present. E.g. if we have some splitted staves and we want
> > to have voices behave differently depending on whether they are in a
> > separate staff or in the common staff. So for this it would be nice if we
> > could simply save information in the Staff context that tells us things
> > like how many different Parts we currently have in the Staff, for
> > example.
> >
> > For example we could handle properties that begin with „custom” as custom
> > properties, so we could say \override Staff.custom-my-property =
> > something.
>
> You can define new properties with a predicate as
> explained here:
>
> https://extending-lilypond.readthedocs.io/en/latest/properties-types.html#ne
> w-properties
>
> I don't think we would want to make custom engravers
> different from the default ones here, not the least
> because any user-written engraver is a candidate for
> being included in the core. If your property really
> accepts anything, just give it the predicate scheme? .
>
> > Second it would be very useful if we could somehow give engravers some
> > sort of filtering option that would allow us to make them not to listen
> > to certain events, so that we’d basically be able to disable/enable
> > engravers outside of withing the score, or even disable engravers for
> > certain Types of events or for events that fit some condition (like
> > having a certain tag).
>
> What is the use case?
>
> It doesn't sound bad, but I doubt it will fully answer
> problems related to grobs created not in reaction to
> events but in reaction to other grobs via acknowledgers.
> So my own vague take on "pushing grobs to contexts",
> part combining, cross-staff, and all that would rather
> be adding the ability to start and stop engravers midway.
> Not that I have any more precise ideas than this though.
>
> > Third: Using font-features with Lilypond is a bit weird, as using
> > \override
> > #'(font-features featureA featureB bla bla . ()) will override any
> > previously applied font-features. So I suggest adding markup functions
> > addFontFeature and removeFontFeature like in the appended example to make
> > this easier.
> >
> > What are your takes on this?
>
> Sounds useful. \removeFontFeature sounds more like a
> specialized use case though. I'd add just \with-font-feature
> (dashes are the convention for markup commands). Also
> note that you can rewrite it more simply (in my opinion) as
>
> #(define-markup-command (with-font-feature layout props feat m) (string?
> markup?)
> #:properties ((font-features '()))
> (interpret-markup layout
> `(((font-features . (,feat . ,font-features))) .
> ,props)
> m))
>
> Best,
> Jean\paper {
#(define fonts
(make-pango-font-tree "TeX Gyre Schola"
"TeX Gyre Heros"
"TeX Gyre Cursor"
1))
}
#(define-markup-command (with-font-feature layout props feats m) ((lambda (x) (or (list? x) (string? x))) markup?)
#:properties ((font-features '()))
(if (string? feats)
(interpret-markup layout
`(((font-features . (,feats . ,font-features))) . ,props)
m)
(interpret-markup layout
`(((font-features . ,(append feats font-features))) . ,props)
m)))
Re: „Anonymous” properties, deafening engravers and font features
Hello Lukas, hello Jean,
Using details works very well, thank you for that. I’ve appended an example I
just did for Paolo Prete for overriding properties of different articulation
types (although it is not limited to that) using this details property.
@Jean: I just don’t want to bother you developers with a feature request if by
stupidity I request for something that does already exists, like the details
property Lukas mentioned.
One use case is: We can have scores with multiple time signatures by moving
some engravers from Score to Staff (or whatever). Now if we have a piece where
we have a section with mixed time signatures, we might want to kind of switch
between a Score engraver and a Staff engraver within the music. Of course as
you said this would just need switching engraver on and off withing music.
Maybe one could have an engraver property one can set to block the engraver
from outputting stuff?
About the font-feature thing you’re probably right, I just thought that there
is no reason to override anything if we do not change anything. Removing font
features can be useful if we have activated some feature (e.g. by saying
\override something.font-features #' (smcp)) but then we have one particular
case where we do not want that feature.
Valentin%%% SNIPPET BEGINS
%%% if proc is a procedure evaluate (proc grob), else return proc as value
#(define (eval-if-proc proc grob)
(if (procedure? proc)
(proc grob)
proc))
%%% retrieves overrides from grob.details.path.key where key is some key function or else from
%%% grob.path.default or default parameter if not exists
#(define ((override-by-details tag path . default) grob)
(let* ((key (tag grob))
(tweak (ly:assoc-get key (ly:assoc-get path (ly:grob-property grob 'details) '()) 'pass))
(default (ly:assoc-get 'default
(ly:assoc-get path (ly:grob-property grob 'details) '())
(if (null? default) default (car default)
(if (equal? tweak 'pass) default tweak)))
%%% articulation type as tag
#(define (articulation-type grob)
(string->symbol (ly:prob-property (ly:grob-property grob 'cause) 'articulation-type)))
\layout {
\context {
\Score
\override Script.font-size = #(override-by-details articulation-type 'font-size)
\override Script.color = #(override-by-details articulation-type 'color)
% This override is only nescessary as somehow if font-size is a procedure it is not evaluated automatically,
% so we need to manually call (ly:grob-property grob 'font-size) once.
\override Script.stencil = #(lambda (grob)
(ly:grob-property grob 'font-size)
(ly:script-interface::print grob))
}
}
\score
{
{
\textLengthOn
\override Script.details.font-size.tenuto = #2
\override Script.details.font-size.accent = #-5
\override Script.details.color.tenuto = #red
\override Script.details.color.marcato = #blue
c'4->^"-5" c'4--^"+2,red" c'4-\tweak #'font-size #-2 -- ^"manual tweak -2" c'-^^"blue" c'-\tweak #'color #green -^^"manual tweak green"
s4*3 |
c'8-- c'-> c'-! c'-^
\temporary\override Script.details.font-size.default = #4
c'8-- c'-> c'-! c'-^
\temporary\override Script.details.color.default = #yellow
c'8-- c'-> c'-! c'-^
\revert Script.details.font-size.default
\revert Script.details.color.default
c'8-- c'-> c'-! c'-^
\override Script.details.color.tenuto = #green
c'8-- c'-> c'-! c'-^
}
}
%%% SNIPPET ENDS
signature.asc
Description: This is a digitally signed message part.
Re: „Anonymous” properties, deafening engravers and font features
Le 18/11/2021 à 21:51, Valentin Petzel a écrit : Hello, I have three ideas for maybe useful features for Lilypond: Let's keep this one here, but next time it would be a good idea to send feature requests to -devel instead. Not all developers read -user. First, Lilypond is very strict about what values grob/context properties can take. While this is generally a good thing it can be hindering, as properties are more or less hard coded. So I suggest that maybe we could have some sort of identifier for „custom” properties that skip the type check. This would be useful for extended scripting where we want to store arbitrary information. For example we might have Staves that should behave differently if certain other Staves are present. E.g. if we have some splitted staves and we want to have voices behave differently depending on whether they are in a separate staff or in the common staff. So for this it would be nice if we could simply save information in the Staff context that tells us things like how many different Parts we currently have in the Staff, for example. For example we could handle properties that begin with „custom” as custom properties, so we could say \override Staff.custom-my-property = something. You can define new properties with a predicate as explained here: https://extending-lilypond.readthedocs.io/en/latest/properties-types.html#new-properties I don't think we would want to make custom engravers different from the default ones here, not the least because any user-written engraver is a candidate for being included in the core. If your property really accepts anything, just give it the predicate scheme? . Second it would be very useful if we could somehow give engravers some sort of filtering option that would allow us to make them not to listen to certain events, so that we’d basically be able to disable/enable engravers outside of withing the score, or even disable engravers for certain Types of events or for events that fit some condition (like having a certain tag). What is the use case? It doesn't sound bad, but I doubt it will fully answer problems related to grobs created not in reaction to events but in reaction to other grobs via acknowledgers. So my own vague take on "pushing grobs to contexts", part combining, cross-staff, and all that would rather be adding the ability to start and stop engravers midway. Not that I have any more precise ideas than this though. Third: Using font-features with Lilypond is a bit weird, as using \override #'(font-features featureA featureB bla bla . ()) will override any previously applied font-features. So I suggest adding markup functions addFontFeature and removeFontFeature like in the appended example to make this easier. What are your takes on this? Sounds useful. \removeFontFeature sounds more like a specialized use case though. I'd add just \with-font-feature (dashes are the convention for markup commands). Also note that you can rewrite it more simply (in my opinion) as #(define-markup-command (with-font-feature layout props feat m) (string? markup?) #:properties ((font-features '())) (interpret-markup layout `(((font-features . (,feat . ,font-features))) . ,props) m)) Best, Jean
Re: „Anonymous” properties, deafening engravers and font features
Valentin Petzel writes: > Hello, > > I have three ideas for maybe useful features for Lilypond: > > First, Lilypond is very strict about what values grob/context > properties can take. While this is generally a good thing it can be > hindering, as properties are more or less hard coded. So I suggest > that maybe we could have some sort of identifier for „custom” > properties that skip the type check. This would be useful for extended > scripting where we want to store arbitrary information. That seems like a complete confused proposal to me since LilyPond is strict about the values of properties because it has to be able to _interpret_ them. If you want to define your _own_ properties without any constraint whatsoever (what is then going to be able to interpret just _any_ Scheme value you throw at it?), you can define them to be of type scheme? . > For example we might have Staves that should behave differently if > certain other Staves are present. E.g. if we have some splitted staves > and we want to have voices behave differently depending on whether > they are in a separate staff or in the common staff. So? > So for this it would be nice if we could simply save information in > the Staff context that tells us things like how many different Parts > we currently have in the Staff, for example. How are you going to do that without the value having _any_ predictable type or structure? > Second it would be very useful if we could somehow give engravers some > sort of filtering option that would allow us to make them not to > listen to certain events, so that we’d basically be able to > disable/enable engravers outside of withing the score, or even disable > engravers for certain Types of events or for events that fit some > condition (like having a certain tag). Engravers only listen to a given type of event. Removing events with a certain tag is done by the \removeWithTag command. So what is your proposal supposed to achieve exactly? > Third: Using font-features with Lilypond is a bit weird, as using \override > #'(font-features featureA featureB bla bla . ()) will override any previously > applied font-features. So I suggest adding markup functions addFontFeature > and > removeFontFeature like in the appended example to make this easier. I have no idea about font handling so I cannot say anything concerning that. > What are your takes on this? I don't see what you propose that isn't already covered. Perhaps some actual examples of what you want to achieve would help? -- David Kastrup
Re: „Anonymous” properties, deafening engravers and font features
Hi Valentin, For example we might have Staves that should behave differently if certain other Staves are present. E.g. if we have some splitted staves and we want to have voices behave differently depending on whether they are in a separate staff or in the common staff. So for this it would be nice if we could simply save information in the Staff context that tells us things like how many different Parts we currently have in the Staff, for example. For example we could handle properties that begin with „custom” as custom properties, so we could say \override Staff.custom-my-property = something. Can't we already do this within the details property of grobs? So not for a whole context (as in your Staff example), but you can already do \override Staff.StaffSymbol.details.my-property = "I am too hard to play" or in very much any other grob. Lukas
„Anonymous” properties, deafening engravers and font features
Hello,
I have three ideas for maybe useful features for Lilypond:
First, Lilypond is very strict about what values grob/context properties can
take. While this is generally a good thing it can be hindering, as properties
are more or less hard coded. So I suggest that maybe we could have some sort
of identifier for „custom” properties that skip the type check. This would be
useful for extended scripting where we want to store arbitrary information.
For example we might have Staves that should behave differently if certain
other Staves are present. E.g. if we have some splitted staves and we want to
have voices behave differently depending on whether they are in a separate
staff or in the common staff. So for this it would be nice if we could simply
save information in the Staff context that tells us things like how many
different Parts we currently have in the Staff, for example.
For example we could handle properties that begin with „custom” as custom
properties, so we could say \override Staff.custom-my-property = something.
Second it would be very useful if we could somehow give engravers some sort of
filtering option that would allow us to make them not to listen to certain
events, so that we’d basically be able to disable/enable engravers outside of
withing the score, or even disable engravers for certain Types of events or
for events that fit some condition (like having a certain tag).
Third: Using font-features with Lilypond is a bit weird, as using \override
#' (font-features featureA featureB bla bla . ()) will override any previously
applied font-features. So I suggest adding markup functions addFontFeature and
removeFontFeature like in the appended example to make this easier.
What are your takes on this?
Cheers,
Valentin#(define-markup-command (addFontFeature layout props feat m) (string? markup?)
(let ((feats (ly:chain-assoc-get 'font-features props '(
(interpret-markup layout props
(if (member feat feats)
m
(markup #:override (cons 'font-features (cons feat feats)) m)
#(define-markup-command (removeFontFeature layout props feat m) (string? markup?)
(define (false-if-empty l) (if (null? l) #f l))
(let ((feats (ly:chain-assoc-get 'font-features props '(
(interpret-markup layout props
(if (not (member feat feats))
m
(markup #:override (cons 'font-features (false-if-empty (delete feat feats))) m)
\paper {
#(define fonts
(make-pango-font-tree "TeX Gyre Schola"
"TeX Gyre Heros"
"TeX Gyre Cursor"
1))
}
\markup { regular123 \addFontFeature "onum" { add123 \removeFontFeature "onum" add+remove123 add-after-remove123 } }
signature.asc
Description: This is a digitally signed message part.
