Re: macro for \once\override
On 2020-08-29 10:38 am, David Kastrup wrote:
Aaron Hill writes:
Is this pushing things too far?
Well, essentially a similar problem. How do you figure out the
difference between setting something to a context mod, and making a
smart alist modification?
I do not believe there are any context or grob properties that accept
ly:context-mod?. But who knows what the future might hold.
It could be reasonable that the "\override Foo \with { ... }" pattern
implies the nested use of \with, meaning you could not assign a context
mod in that syntax. You would have to revert to the existing "\override
Foo = \with { ... }" form.
But it seems a shame that \tweak does not get the enjoy the same
benefits. I guess you would have to simply decide that \tweak always
assumes ly:context-mod? is a smart alist modifier.
-- Aaron Hill
Re: macro for \once\override
Aaron Hill writes:
> On 2020-08-29 6:44 am, David Kastrup wrote:
>> Hm. \with instead of = would even fit into the parser. But that
>> leaves
>> tweaks in the lurch.
>
> Not sure I am following. Are you indicating that something like...
>
>
> \once \override LaissezVibrerTie.details
> \with { ratio = #0.5 height-limit = #2 }
> b'4\laissezVibrer
>
>
> ...could be made to work
By changing the parser.
> but not...
>
>
> b'4
> -\tweak details \with { ratio = #0.5 height-limit = #2 }
> \laissezVibrer
>
>
> ?
Well, \with ... is a valid expression, so this would already be
syntactically accepted by LilyPond. How do you distinguish tweaking an
alist intelligently with just setting a property to a context mod?
> Another thought is whether nested use of \with makes sense. Consider:
>
>
> \version "2.20.0"
>
> overrideII =
> #(define-music-function
> (prop mods)
> (key-list? ly:context-mod?)
> (define (assign? mod) (eq? 'assign (car mod)))
> (define (overrides prop mods)
> (append-map
> (lambda (mod)
> (let ((subprop (cadr mod))
> (value (caddr mod)))
> (if (ly:context-mod? value)
> (overrides (append prop (list subprop)) value)
> (list #{ \override #prop . #subprop = #value #}
> (filter assign? (ly:get-context-mods mods
> #{ #@(overrides prop mods) #})
>
> \include "predefined-guitar-fretboards.ly"
> \storePredefinedDiagram #default-fret-table \chordmode { c' }
> #guitar-tuning
> #"x;1-1-(;3-2;3-3;3-4;1-1-);"
> <<
> \new ChordNames {
> \chordmode { c1 | c | c | d }
> }
> \new FretBoards {
> % Set global properties of fret diagram
> \overrideII FretBoard \with {
> size = #1.2
> fret-diagram-details = \with {
> finger-code = #'in-dot
> dot-color = #'white
> }
> }
> \chordmode {
> c
> \once \overrideII FretBoard \with {
> size = #1.0
> fret-diagram-details = \with {
> barre-type = #'straight
> dot-color = #'black
> finger-code = #'below-string
> }
> }
> c'
> \once \overrideII FretBoard.fret-diagram-details
> \with {
> barre-type = #'none
> number-type = #'arabic
> orientation = #'landscape
> mute-string = #"M"
> label-dir = #LEFT
> dot-color = #'black
> }
> c'
> \once \overrideII FretBoard.fret-diagram-details
> \with {
> finger-code = #'below-string
> dot-radius = #0.35
> dot-position = #0.5
> fret-count = #3
> }
> d
> }
> }
> \new Voice {
> c'1 | c' | c' | d'
> }
>>>
>
>
> Is this pushing things too far?
Well, essentially a similar problem. How do you figure out the
difference between setting something to a context mod, and making a
smart alist modification?
--
David Kastrup
Re: macro for \once\override
On 2020-08-29 6:44 am, David Kastrup wrote:
Hm. \with instead of = would even fit into the parser. But that
leaves
tweaks in the lurch.
Not sure I am following. Are you indicating that something like...
\once \override LaissezVibrerTie.details
\with { ratio = #0.5 height-limit = #2 }
b'4\laissezVibrer
...could be made to work but not...
b'4
-\tweak details \with { ratio = #0.5 height-limit = #2 }
\laissezVibrer
?
Another thought is whether nested use of \with makes sense. Consider:
\version "2.20.0"
overrideII =
#(define-music-function
(prop mods)
(key-list? ly:context-mod?)
(define (assign? mod) (eq? 'assign (car mod)))
(define (overrides prop mods)
(append-map
(lambda (mod)
(let ((subprop (cadr mod))
(value (caddr mod)))
(if (ly:context-mod? value)
(overrides (append prop (list subprop)) value)
(list #{ \override #prop . #subprop = #value #}
(filter assign? (ly:get-context-mods mods
#{ #@(overrides prop mods) #})
\include "predefined-guitar-fretboards.ly"
\storePredefinedDiagram #default-fret-table \chordmode { c' }
#guitar-tuning
#"x;1-1-(;3-2;3-3;3-4;1-1-);"
<<
\new ChordNames {
\chordmode { c1 | c | c | d }
}
\new FretBoards {
% Set global properties of fret diagram
\overrideII FretBoard \with {
size = #1.2
fret-diagram-details = \with {
finger-code = #'in-dot
dot-color = #'white
}
}
\chordmode {
c
\once \overrideII FretBoard \with {
size = #1.0
fret-diagram-details = \with {
barre-type = #'straight
dot-color = #'black
finger-code = #'below-string
}
}
c'
\once \overrideII FretBoard.fret-diagram-details
\with {
barre-type = #'none
number-type = #'arabic
orientation = #'landscape
mute-string = #"M"
label-dir = #LEFT
dot-color = #'black
}
c'
\once \overrideII FretBoard.fret-diagram-details
\with {
finger-code = #'below-string
dot-radius = #0.35
dot-position = #0.5
fret-count = #3
}
d
}
}
\new Voice {
c'1 | c' | c' | d'
}
Is this pushing things too far?
-- Aaron Hill
Re: macro for \once\override
> \propertyTweak finger-code #'below-string > FretBoard.fret-diagram-details > > is completely indistinguishable from > > \propertyTweak fret-diagram-details.finger-code #'below-string > FretBoard > > So any commands stacked before this last \propertyTweak command have > no way of knowing that they are supposed to assume > fret-diagram-details as a given. OK, thanks for the explanation. Werner
Re: macro for \once\override
On 2020-08-29 6:37 am, David Kastrup wrote:
Aaron Hill writes:
On 2020-08-29 5:23 am, David Kastrup wrote:
Wols Lists writes:
On 29/08/20 05:45, Werner LEMBERG wrote:
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details.barre-type =
#'straight
\once \override FretBoard.fret-diagram-details.dot-color =
#'black
\once \override FretBoard.fret-diagram-details.finger-code =
#'below-string
c'
Unfortunately this might well require re-writing the parser, but it
struck me it might be a nice idea to nick an idea from other object
oriented languages as follows ...
\once \override FretBoard.size = #'1.0
\once \override \using FretBoard.fret-diagram-details {
.barre-type = #'straight
.dot-color = #'black
.finger-code = #'below-string
}
c'
What's wrong with
\once \override FretBoard.fret-diagram-details =
#'((barre-type . straight)
(dot-color . black)
(finger-code . below-string))
I mean, I am as proud as anybody that separate subproperty overrides
don't cause LilyPond to go down in flames any more, but this is an
alist, after all.
In my testing, that overwrites any existing overrides on the
fret-diagram-details property, so it is not quite the same thing.
The only preexisting fret-diagram-details entry according to the
internals guide is finger-code , and that one's in there.
Apologies for not being clearer. I was not talking about that specific
bit of code, rather using that construct in the larger example that
Werner posted. In the snippet, some elements of the
fret-diagram-details property were \overridden earlier and those would
not be persisted if you swap out the entire alist.
-- Aaron Hill
Re: macro for \once\override
Aaron Hill writes:
> No need to rewrite anything. We can use \with to assist with this
> pattern:
>
>
> overrideII =
> #(define-music-function
> (prop mods)
> (key-list? ly:context-mod?)
> (define (assign? mod) (eq? 'assign (car mod)))
> (define (proc mod)
> (let ((subprop (cadr mod))
> (value (caddr mod)))
> #{ \override #prop . #subprop = #value #}))
> #{ #@(map proc (filter assign? (ly:get-context-mods mods))) #})
>
>
> While there is almost certainly a better name than overrideII, it
> permits the following:
>
>
> \once \override FretBoard.fret-diagram-details.barre-type = #'none
> \once \override FretBoard.fret-diagram-details.number-type = #'arabic
> \once \override FretBoard.fret-diagram-details.orientation = #'landscape
> \once \override FretBoard.fret-diagram-details.mute-string = #"M"
> \once \override FretBoard.fret-diagram-details.label-dir = #LEFT
> \once \override FretBoard.fret-diagram-details.dot-color = #'black
> %% ...becomes...
> \once \overrideII FretBoard.fret-diagram-details
> \with {
> barre-type = #'none
> number-type = #'arabic
> orientation = #'landscape
> mute-string = #"M"
> label-dir = #LEFT
> dot-color = #'black
> }
>
Hm. \with instead of = would even fit into the parser. But that leaves
tweaks in the lurch.
--
David Kastrup
Re: macro for \once\override
Aaron Hill writes:
> On 2020-08-29 5:23 am, David Kastrup wrote:
>> Wols Lists writes:
>>
>>> On 29/08/20 05:45, Werner LEMBERG wrote:
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details.barre-type =
#'straight
\once \override FretBoard.fret-diagram-details.dot-color =
#'black
\once \override FretBoard.fret-diagram-details.finger-code =
#'below-string
c'
>>> Unfortunately this might well require re-writing the parser, but it
>>> struck me it might be a nice idea to nick an idea from other object
>>> oriented languages as follows ...
>>> \once \override FretBoard.size = #'1.0
>>> \once \override \using FretBoard.fret-diagram-details {
>>> .barre-type = #'straight
>>> .dot-color = #'black
>>> .finger-code = #'below-string
>>> }
>>> c'
>> What's wrong with
>> \once \override FretBoard.fret-diagram-details =
>> #'((barre-type . straight)
>>(dot-color . black)
>>(finger-code . below-string))
>> I mean, I am as proud as anybody that separate subproperty overrides
>> don't cause LilyPond to go down in flames any more, but this is an
>> alist, after all.
>
> In my testing, that overwrites any existing overrides on the
> fret-diagram-details property, so it is not quite the same thing.
The only preexisting fret-diagram-details entry according to the
internals guide is finger-code , and that one's in there.
--
David Kastrup
Re: macro for \once\override
On 2020-08-29 5:23 am, David Kastrup wrote:
Wols Lists writes:
On 29/08/20 05:45, Werner LEMBERG wrote:
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details.barre-type =
#'straight
\once \override FretBoard.fret-diagram-details.dot-color =
#'black
\once \override FretBoard.fret-diagram-details.finger-code =
#'below-string
c'
Unfortunately this might well require re-writing the parser, but it
struck me it might be a nice idea to nick an idea from other object
oriented languages as follows ...
\once \override FretBoard.size = #'1.0
\once \override \using FretBoard.fret-diagram-details {
.barre-type = #'straight
.dot-color = #'black
.finger-code = #'below-string
}
c'
What's wrong with
\once \override FretBoard.fret-diagram-details =
#'((barre-type . straight)
(dot-color . black)
(finger-code . below-string))
I mean, I am as proud as anybody that separate subproperty overrides
don't cause LilyPond to go down in flames any more, but this is an
alist, after all.
In my testing, that overwrites any existing overrides on the
fret-diagram-details property, so it is not quite the same thing.
-- Aaron Hill
Re: macro for \once\override
On 2020-08-28 9:45 pm, Werner LEMBERG wrote:
No. I'm against it. Introducing abbreviations into examples is a
slippery slope and sets a bad precedent. In my scores I use \t for
\tuplet, but I would never inflict that on any public example, even
to save space. Wrapped lines are not a visual or semantic issue to
me at least. Please don't do this.
Sigh. I must admit that I don't understand this purism, which I
almost consider as l'art pour l'art.
Attached are the current version, my suggestion using an
abbreviation, and an alternative that uses wrapping only.
Of the new ones, which one do you consider more readable?
Why repeat \once that many times? Just wrap up all the overrides
together and \once it once:
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details.barre-type = #'straight
\once \override FretBoard.fret-diagram-details.dot-color = #'black
\once \override FretBoard.fret-diagram-details.finger-code =
#'below-string
%% ...becomes...
\once {
\override FretBoard.size = #'1.0
\override FretBoard.fret-diagram-details.barre-type = #'straight
\override FretBoard.fret-diagram-details.dot-color = #'black
\override FretBoard.fret-diagram-details.finger-code = #'below-string
}
-- Aaron Hill
Re: macro for \once\override
On 2020-08-29 3:19 am, Wols Lists wrote:
On 29/08/20 05:45, Werner LEMBERG wrote:
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details.barre-type =
#'straight
\once \override FretBoard.fret-diagram-details.dot-color =
#'black
\once \override FretBoard.fret-diagram-details.finger-code =
#'below-string
c'
Unfortunately this might well require re-writing the parser, but it
struck me it might be a nice idea to nick an idea from other object
oriented languages as follows ...
\once \override FretBoard.size = #'1.0
\once \override \using FretBoard.fret-diagram-details {
.barre-type = #'straight
.dot-color = #'black
.finger-code = #'below-string
}
c'
No need to rewrite anything. We can use \with to assist with this
pattern:
overrideII =
#(define-music-function
(prop mods)
(key-list? ly:context-mod?)
(define (assign? mod) (eq? 'assign (car mod)))
(define (proc mod)
(let ((subprop (cadr mod))
(value (caddr mod)))
#{ \override #prop . #subprop = #value #}))
#{ #@(map proc (filter assign? (ly:get-context-mods mods))) #})
While there is almost certainly a better name than overrideII, it
permits the following:
\once \override FretBoard.fret-diagram-details.barre-type = #'none
\once \override FretBoard.fret-diagram-details.number-type = #'arabic
\once \override FretBoard.fret-diagram-details.orientation = #'landscape
\once \override FretBoard.fret-diagram-details.mute-string = #"M"
\once \override FretBoard.fret-diagram-details.label-dir = #LEFT
\once \override FretBoard.fret-diagram-details.dot-color = #'black
%% ...becomes...
\once \overrideII FretBoard.fret-diagram-details
\with {
barre-type = #'none
number-type = #'arabic
orientation = #'landscape
mute-string = #"M"
label-dir = #LEFT
dot-color = #'black
}
-- Aaron Hill
Re: macro for \once\override
Wols Lists writes:
> On 29/08/20 05:45, Werner LEMBERG wrote:
>> \once \override FretBoard.size = #'1.0
>> \once \override FretBoard.fret-diagram-details.barre-type = #'straight
>> \once \override FretBoard.fret-diagram-details.dot-color = #'black
>> \once \override FretBoard.fret-diagram-details.finger-code =
>> #'below-string
>> c'
>
> Unfortunately this might well require re-writing the parser, but it
> struck me it might be a nice idea to nick an idea from other object
> oriented languages as follows ...
>
> \once \override FretBoard.size = #'1.0
> \once \override \using FretBoard.fret-diagram-details {
> .barre-type = #'straight
> .dot-color = #'black
> .finger-code = #'below-string
> }
> c'
What's wrong with
\once \override FretBoard.fret-diagram-details =
#'((barre-type . straight)
(dot-color . black)
(finger-code . below-string))
I mean, I am as proud as anybody that separate subproperty overrides
don't cause LilyPond to go down in flames any more, but this is an
alist, after all.
--
David Kastrup
Re: macro for \once\override
Werner LEMBERG writes: >>> BTW, would it be possible to enhance `\propertyTweak` to write >>> >>> \propertyTweak fret-diagram-details.dot-color #'white >>> FretBoard >>> >>> as >>> >>> \propertyTweak dot-color #'white >>> FretBoard.fret-diagram-details ? >> >> Have you even tried? > > Only the stacking case: > > \once \propertyTweak barre-type #'straight > \propertyTweak dot-color #'black > \propertyTweak finger-code #'below-string >FretBoard.fret-diagram-details > > => error: bad grob property path (dot-color) > > Sorry for the simplification. > >> With the obvious consequence that it makes no difference for >> stacking _multiple_ \propertyTweak commands, so it doesn't help a >> lot in your case. > > I don't understand this remark. Please elaborate. \propertyTweak finger-code #'below-string FretBoard.fret-diagram-details is completely indistinguishable from \propertyTweak fret-diagram-details.finger-code #'below-string FretBoard So any commands stacked before this last \propertyTweak command have no way of knowing that they are supposed to assume fret-diagram-details as a given. >> And actually using this syntax for the final \propertyTweak is >> likely going to be a lot more confusing than just staying like you >> are. > > I agree. It was a bad example, and the one above should better > demonstrate what I'm looking for. No idea what you mean. -- David Kastrup
Re: macro for \once\override
>> BTW, would it be possible to enhance `\propertyTweak` to write >> >> \propertyTweak fret-diagram-details.dot-color #'white >> FretBoard >> >> as >> >> \propertyTweak dot-color #'white >> FretBoard.fret-diagram-details ? > > Have you even tried? Only the stacking case: \once \propertyTweak barre-type #'straight \propertyTweak dot-color #'black \propertyTweak finger-code #'below-string FretBoard.fret-diagram-details => error: bad grob property path (dot-color) Sorry for the simplification. > With the obvious consequence that it makes no difference for > stacking _multiple_ \propertyTweak commands, so it doesn't help a > lot in your case. I don't understand this remark. Please elaborate. > And actually using this syntax for the final \propertyTweak is > likely going to be a lot more confusing than just staying like you > are. I agree. It was a bad example, and the one above should better demonstrate what I'm looking for. Werner
Re: macro for \once\override
On 29/08/20 05:45, Werner LEMBERG wrote:
> \once \override FretBoard.size = #'1.0
> \once \override FretBoard.fret-diagram-details.barre-type = #'straight
> \once \override FretBoard.fret-diagram-details.dot-color = #'black
> \once \override FretBoard.fret-diagram-details.finger-code =
> #'below-string
> c'
Unfortunately this might well require re-writing the parser, but it
struck me it might be a nice idea to nick an idea from other object
oriented languages as follows ...
\once \override FretBoard.size = #'1.0
\once \override \using FretBoard.fret-diagram-details {
.barre-type = #'straight
.dot-color = #'black
.finger-code = #'below-string
}
c'
Cheers,
Wol
Re: macro for \once\override
Werner LEMBERG writes: >> Maybe >> >> \void \displayLilyMusic >> \once >> \propertyTweak color #red >> \propertyTweak font-size #3 >> \propertyTweak direction #UP Voice.Slur >> >> helps? > > It does, thanks a lot! I didn't have this function on my radar, and > it isn't documented in the NR at all. > > Attached a version using \propertyTweak. Right now, this wins > w.r.t. readability IMHO. > > BTW, would it be possible to enhance `\propertyTweak` to write > > \propertyTweak fret-diagram-details.dot-color #'white > FretBoard > > as > > \propertyTweak dot-color #'white > FretBoard.fret-diagram-details ? Have you even tried? This works and produces identical results. With the obvious consequence that it makes no difference for stacking _multiple_ \propertyTweak commands, so it doesn't help a lot in your case. And actually using this syntax for the final \propertyTweak is likely going to be a lot more confusing than just staying like you are. -- David Kastrup
Re: macro for \once\override
> Maybe
>
> \void \displayLilyMusic
> \once
> \propertyTweak color #red
> \propertyTweak font-size #3
> \propertyTweak direction #UP Voice.Slur
>
> helps?
It does, thanks a lot! I didn't have this function on my radar, and
it isn't documented in the NR at all.
Attached a version using \propertyTweak. Right now, this wins
w.r.t. readability IMHO.
BTW, would it be possible to enhance `\propertyTweak` to write
\propertyTweak fret-diagram-details.dot-color #'white
FretBoard
as
\propertyTweak dot-color #'white
FretBoard.fret-diagram-details ?
Werner
\include "predefined-guitar-fretboards.ly"
\storePredefinedDiagram #default-fret-table \chordmode { c' }
#guitar-tuning
#"x;1-1-(;3-2;3-3;3-4;1-1-);"
<<
\new ChordNames {
\chordmode { c1 | c | c | d }
}
\new FretBoards {
% Set global properties of fret diagram
\propertyTweak size #1.2
FretBoards.FretBoard
\propertyTweak fret-diagram-details.finger-code #'in-dot
\propertyTweak fret-diagram-details.dot-color #'white
FretBoard
\chordmode {
c
\once \propertyTweak size #1.0
FretBoard
\once \propertyTweak fret-diagram-details.barre-type #'straight
\propertyTweak fret-diagram-details.dot-color #'black
\propertyTweak fret-diagram-details.finger-code #'below-string
FretBoard
c'
\once \propertyTweak fret-diagram-details.barre-type #'none
\propertyTweak fret-diagram-details.number-type #'arabic
\propertyTweak fret-diagram-details.orientation #'landscape
\propertyTweak fret-diagram-details.mute-string #"M"
\propertyTweak fret-diagram-details.label-dir #LEFT
\propertyTweak fret-diagram-details.dot-color #'black
FretBoard
c'
\once \propertyTweak fret-diagram-details.finger-code #'below-string
\propertyTweak fret-diagram-details.dot-radius #0.35
\propertyTweak fret-diagram-details.dot-position #0.5
\propertyTweak fret-diagram-details.fret-count #3
FretBoard
d
}
}
\new Voice {
c'1 | c' | c' | d'
}
>>
Re: macro for \once\override
> No. I'm against it. Introducing abbreviations into examples is a
> slippery slope and sets a bad precedent. In my scores I use \t for
> \tuplet, but I would never inflict that on any public example, even
> to save space. Wrapped lines are not a visual or semantic issue to
> me at least. Please don't do this.
Sigh. I must admit that I don't understand this purism, which I
almost consider as l'art pour l'art.
Attached are the current version, my suggestion using an
abbreviation, and an alternative that uses wrapping only.
Of the new ones, which one do you consider more readable?
Werner
\include "predefined-guitar-fretboards.ly"
\storePredefinedDiagram #default-fret-table \chordmode { c' }
#guitar-tuning
#"x;1-1-(;3-2;3-3;3-4;1-1-);"
<<
\new ChordNames {
\chordmode { c1 | c | c | d }
}
\new FretBoards {
% Set global properties of fret diagram
\override FretBoards.FretBoard.size = #'1.2
\override FretBoard.fret-diagram-details.finger-code = #'in-dot
\override FretBoard.fret-diagram-details.dot-color = #'white
\chordmode {
c
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details.barre-type = #'straight
\once \override FretBoard.fret-diagram-details.dot-color = #'black
\once \override FretBoard.fret-diagram-details.finger-code =
#'below-string
c'
\once \override FretBoard.fret-diagram-details.barre-type = #'none
\once \override FretBoard.fret-diagram-details.number-type = #'arabic
\once \override FretBoard.fret-diagram-details.orientation = #'landscape
\once \override FretBoard.fret-diagram-details.mute-string = #"M"
\once \override FretBoard.fret-diagram-details.label-dir = #LEFT
\once \override FretBoard.fret-diagram-details.dot-color = #'black
c'
\once \override FretBoard.fret-diagram-details.finger-code =
#'below-string
\once \override FretBoard.fret-diagram-details.dot-radius = #0.35
\once \override FretBoard.fret-diagram-details.dot-position = #0.5
\once \override FretBoard.fret-diagram-details.fret-count = #3
d
}
}
\new Voice {
c'1 | c' | c' | d'
}
>>
\include "predefined-guitar-fretboards.ly"
\storePredefinedDiagram #default-fret-table \chordmode { c' }
#guitar-tuning
#"x;1-1-(;3-2;3-3;3-4;1-1-);"
% Shorthand for '\once \override foo = bar', which becomes
% '\oo foo bar'.
oo = #(define-music-function
(parser location grob-path value)
(symbol-list? scheme?)
#{ \once \override #grob-path = #value #})
<<
\new ChordNames {
\chordmode { c1 | c | c | d }
}
\new FretBoards {
% Set global properties of fret diagram
\override FretBoards.FretBoard.size = #'1.2
\override FretBoard.fret-diagram-details.finger-code = #'in-dot
\override FretBoard.fret-diagram-details.dot-color = #'white
\chordmode {
c
\oo FretBoard.size #'1.0
\oo FretBoard.fret-diagram-details.barre-type #'straight
\oo FretBoard.fret-diagram-details.dot-color #'black
\oo FretBoard.fret-diagram-details.finger-code #'below-string
c'
\oo FretBoard.fret-diagram-details.barre-type #'none
\oo FretBoard.fret-diagram-details.number-type #'arabic
\oo FretBoard.fret-diagram-details.orientation #'landscape
\oo FretBoard.fret-diagram-details.mute-string #"M"
\oo FretBoard.fret-diagram-details.label-dir #LEFT
\oo FretBoard.fret-diagram-details.dot-color #'black
c'
\oo FretBoard.fret-diagram-details.finger-code #'below-string
\oo FretBoard.fret-diagram-details.dot-radius #0.35
\oo FretBoard.fret-diagram-details.dot-position #0.5
\oo FretBoard.fret-diagram-details.fret-count #3
d
}
}
\new Voice {
c'1 | c' | c' | d'
}
>>
\include "predefined-guitar-fretboards.ly"
\storePredefinedDiagram #default-fret-table \chordmode { c' }
#guitar-tuning
#"x;1-1-(;3-2;3-3;3-4;1-1-);"
<<
\new ChordNames {
\chordmode { c1 | c | c | d }
}
\new FretBoards {
% Set global properties of fret diagram
\override FretBoards.FretBoard.size = #'1.2
\override FretBoard.fret-diagram-details.finger-code = #'in-dot
\override FretBoard.fret-diagram-details.dot-color = #'white
\chordmode {
c
\once \override FretBoard.size = #'1.0
\once \override FretBoard.fret-diagram-details
.barre-type = #'straight
\once \override FretBoard.fret-diagram-details
.dot-color = #'black
\once \override FretBoard.fret-diagram-details
.finger-code = #'below-string
c'
\once \override FretBoard.fret-diagram-details
.barre-type = #'none
\once \override FretBoard.fret-diagram-details
.number-type = #'arabic
\once \override
Re: macro for \once\override
On 28/08/2020 20:42, Werner LEMBERG wrote: Well, we have to make a compromise. The PDF document has a small line width, and you can't scroll horizontally... Theoretically, the snippet could be printed with a smaller font size, but this doesn't look very pretty IMHO. I consider the `\oo` shorthand both innocuous and simple enough for a snippet. My preference is the one that you said is inappropriate: \once \override Very.Long.Grob.PropertyToBeChanged = foo If we introduce oo, then that adds extra lines to the snippet, and it confuses the override (which is the purpose of the snippet) with the convenience function (which is not necessary for the operation of the snippet). If you have to split 20 very long `\once\override` line this way, it's (a) very hard to read, and (b) much longer than the few lines introducing the little function. I think that the benefit of the improvement in the typography is outweighed by the increased difficulty of understanding the snippet. I disagree. There are snippets with *extremely* sophisticated Scheme code. What I'm going to introduce is very basic. Complex or basic, if it's extraneous to the example, then you don't want it. And especially, if the intent is show the use of \once \override, using an abbreviation for it obscures the whole point of the example. Some of us have great difficulty getting to grips with Scheme :-) ANY use of it unnecessarily is an obstacle to understanding, sorry. Cheers, Wol
Re: macro for \once\override
No. I'm against it. Introducing abbreviations into examples is a slippery slope and sets a bad precedent. In my scores I use \t for \tuplet, but I would never inflict that on any public example, even to save space. Wrapped lines are not a visual or semantic issue to me at least. Please don't do this. Andrew On 29/08/2020 5:46 am, Werner LEMBERG wrote: Well, we have to make a compromise. The PDF document has a small line width, and you can't scroll horizontally... Then you just have to wrap the line. I'm Mr. Wrap-Line, as can be seen by many of my commits. If I think that wrapping is suboptimal and reduces legibility I hope you have some trust in my decision... Werner
Re: macro for \once\override
Werner LEMBERG writes: >>> Well, we have to make a compromise. The PDF document has a small >>> line width, and you can't scroll horizontally... >> >> Then you just have to wrap the line. > > I'm Mr. Wrap-Line, as can be seen by many of my commits. If I think > that wrapping is suboptimal and reduces legibility I hope you have > some trust in my decision... Maybe \void \displayLilyMusic \once \propertyTweak color #red \propertyTweak font-size #3 \propertyTweak direction #UP Voice.Slur helps? -- David Kastrup
Re: macro for \once\override
>> Well, we have to make a compromise. The PDF document has a small >> line width, and you can't scroll horizontally... > > Then you just have to wrap the line. I'm Mr. Wrap-Line, as can be seen by many of my commits. If I think that wrapping is suboptimal and reduces legibility I hope you have some trust in my decision... Werner
Re: macro for \once\override
>> Well, we have to make a compromise. The PDF document has a small line >> width, and you can't scroll horizontally... >> >> Theoretically, the snippet could be printed with a smaller font size, >> but this doesn't look very pretty IMHO. I consider the `\oo` >> shorthand both innocuous and simple enough for a snippet. >> > > My preference is the one that you said is inappropriate: > > \once \override > Very.Long.Grob.PropertyToBeChanged = foo > > If we introduce oo, then that adds extra lines to the snippet, and > it confuses the override (which is the purpose of the snippet) with > the convenience function (which is not necessary for the operation > of the snippet). If you have to split 20 very long `\once\override` line this way, it's (a) very hard to read, and (b) much longer than the few lines introducing the little function. > I think that the benefit of the improvement in the typography is > outweighed by the increased difficulty of understanding the snippet. I disagree. There are snippets with *extremely* sophisticated Scheme code. What I'm going to introduce is very basic. Werner
Re: macro for \once\override
Werner LEMBERG writes: >>> However, saying >>> >>> \oo VeryLong.Grob.PropertyToBeChanged = foo >>> >>> for this (and only this) snippet is just fine. >> >> I don't think that it makes sense for snippets to introduce >> convenience shorthands unless the snippet in itself tries is about >> showcasing the shorthand. It detracts from the content. > > Well, we have to make a compromise. The PDF document has a small line > width, and you can't scroll horizontally... Then you just have to wrap the line. > Theoretically, the snippet could be printed with a smaller font size, > but this doesn't look very pretty IMHO. I consider the `\oo` > shorthand both innocuous and simple enough for a snippet. I find a line wrap quite less of a distraction. -- David Kastrup
Re: macro for \once\override
On Fri, Aug 28, 2020 at 8:52 AM Werner LEMBERG wrote: > >> However, saying > >> > >> \oo VeryLong.Grob.PropertyToBeChanged = foo > >> > >> for this (and only this) snippet is just fine. > > > > I don't think that it makes sense for snippets to introduce > > convenience shorthands unless the snippet in itself tries is about > > showcasing the shorthand. It detracts from the content. > > Well, we have to make a compromise. The PDF document has a small line > width, and you can't scroll horizontally... > > Theoretically, the snippet could be printed with a smaller font size, > but this doesn't look very pretty IMHO. I consider the `\oo` > shorthand both innocuous and simple enough for a snippet. > My preference is the one that you said is inappropriate: \once \override Very.Long.Grob.PropertyToBeChanged = foo If we introduce oo, then that adds extra lines to the snippet, and it confuses the override (which is the purpose of the snippet) with the convenience function (which is not necessary for the operation of the snippet). I think that the benefit of the improvement in the typography is outweighed by the increased difficulty of understanding the snippet. Thanks, Carl
Re: macro for \once\override
>> However, saying >> >> \oo VeryLong.Grob.PropertyToBeChanged = foo >> >> for this (and only this) snippet is just fine. > > I don't think that it makes sense for snippets to introduce > convenience shorthands unless the snippet in itself tries is about > showcasing the shorthand. It detracts from the content. Well, we have to make a compromise. The PDF document has a small line width, and you can't scroll horizontally... Theoretically, the snippet could be printed with a smaller font size, but this doesn't look very pretty IMHO. I consider the `\oo` shorthand both innocuous and simple enough for a snippet. Werner
Re: macro for \once\override
Werner LEMBERG writes: >>> Because right now LSR is still using this version. >> >> Then that means we have to use that oo code in the NR? I am not sure >> I follow. I'd rather not please. > > Right now I'm checking the NR for bad typography in the PDF version, > which usually means overlong lines. A lot of snippets are directly > imported from the LSR; they are typeset unmodified. One of the > snippets has a bunch of > > \once\overvide VeryLong.Grob.PropertyToBeChanged = foo > > Changing them to > > \once\overvide > VeryLong.Grob.PropertyToBeChanged = foo > > looks bad. However, saying > > \oo VeryLong.Grob.PropertyToBeChanged = foo > > for this (and only this) snippet is just fine. I don't think that it makes sense for snippets to introduce convenience shorthands unless the snippet in itself tries is about showcasing the shorthand. It detracts from the content. -- David Kastrup
Re: macro for \once\override
Werner LEMBERG writes:
>> oo = #(define-music-function (parser location prop value)
>>(symbol-list? scheme?)
>> #{ \once \override #prop = #value #})
>>
>> should likely work fine in 2.18.
>
> Thanks! Aaron provided this version
>
> oo = #(define-music-function (parser location prop value)
> (list? scheme?)
> #{ \once \override $prop = #value #})
>
> and I wonder which one is better...
Well, I prefer not investing the overhead of $ when # is sufficient, and
I prefer using predicates that are specific enough to lead to error
messages at the place where the wrong input is rather than triggering
followup errors.
Given correct input, they should do the same.
--
David Kastrup
Re: macro for \once\override
>> Because right now LSR is still using this version. > > Then that means we have to use that oo code in the NR? I am not sure > I follow. I'd rather not please. Right now I'm checking the NR for bad typography in the PDF version, which usually means overlong lines. A lot of snippets are directly imported from the LSR; they are typeset unmodified. One of the snippets has a bunch of \once\overvide VeryLong.Grob.PropertyToBeChanged = foo Changing them to \once\overvide VeryLong.Grob.PropertyToBeChanged = foo looks bad. However, saying \oo VeryLong.Grob.PropertyToBeChanged = foo for this (and only this) snippet is just fine. Werner
Re: macro for \once\override
Then that means we have to use that oo code in the NR? I am not sure I follow. I'd rather not please. Andrew On 28/08/2020 1:48 pm, Werner LEMBERG wrote: I side step the whole thing by having dynamic expanable macros in the text editor. But this gives overlong lines, which I want to avoid for snippets taken from the LSR and being part of the NR. And why use 2.18? Because right now LSR is still using this version. Werner
Re: macro for \once\override
> oo = #(define-music-function (parser location prop value)
>(symbol-list? scheme?)
> #{ \once \override #prop = #value #})
>
> should likely work fine in 2.18.
Thanks! Aaron provided this version
oo = #(define-music-function (parser location prop value)
(list? scheme?)
#{ \once \override $prop = #value #})
and I wonder which one is better...
Werer
Re: macro for \once\override
> I side step the whole thing by having dynamic expanable macros in > the text editor. But this gives overlong lines, which I want to avoid for snippets taken from the LSR and being part of the NR. > And why use 2.18? Because right now LSR is still using this version. Werner
Re: macro for \once\override
I side step the whole thing by having dynamic expanable macros in the text editor. And why use 2.18? Andrew On 28/08/2020 6:10 am, Werner LEMBERG wrote: Folks, I wonder whether there is a possibility to have a working equivalent to oo = \once\override so that I can say \oo foo.bar = #'baz . It should work with LilyPond 2.18, BTW. A quick search in the internet didn't bring something relevant. Help would be much appreciated. Werner
Re: macro for \once\override
Werner LEMBERG writes:
>>> I wonder whether there is a possibility to have a working equivalent
>>> to
>>>
>>> oo = \once\override
>>>
>>> so that I can say
>>>
>>> \oo foo.bar = #'baz .
>>
>> The best you can aim for is
>>
>> \oo foo.bar #'baz
>
> This would be just fine. The thing is to replace `\once\override`
> with something shorter.
oo = #(define-music-function (parser location prop value) (symbol-list? scheme?)
#{ \once \override #prop = #value #})
should likely work fine in 2.18.
--
David Kastrup
Re: macro for \once\override
> Like this, I would imagine:
>
>
> \version "2.18.2"
>
> oo =
> #(define-music-function
> (parser location grob-path value)
> (list? scheme?)
> #{ \once \override $grob-path = #value #})
Great, thanks!
Werner
Re: macro for \once\override
On 2020-08-27 1:27 pm, David Kastrup wrote:
Werner LEMBERG writes:
Folks,
I wonder whether there is a possibility to have a working equivalent
to
oo = \once\override
so that I can say
\oo foo.bar = #'baz .
It should work with LilyPond 2.18, BTW.
A quick search in the internet didn't bring something relevant.
No, and not in 2.20 either. The best you can aim for is
\oo foo.bar #'baz
Like this, I would imagine:
\version "2.18.2"
oo =
#(define-music-function
(parser location grob-path value)
(list? scheme?)
#{ \once \override $grob-path = #value #})
{ b'4 \oo NoteHead.color #red g'4 a'2 }
-- Aaron Hill
Re: macro for \once\override
>> I wonder whether there is a possibility to have a working equivalent >> to >> >> oo = \once\override >> >> so that I can say >> >> \oo foo.bar = #'baz . > > The best you can aim for is > > \oo foo.bar #'baz This would be just fine. The thing is to replace `\once\override` with something shorter. Werner
Re: macro for \once\override
Werner LEMBERG writes: > Folks, > > > I wonder whether there is a possibility to have a working equivalent > to > > oo = \once\override > > so that I can say > > \oo foo.bar = #'baz . > > It should work with LilyPond 2.18, BTW. > > A quick search in the internet didn't bring something relevant. No, and not in 2.20 either. The best you can aim for is \oo foo.bar #'baz (which is similar to \tweak syntax) but the equals sign is a syntactic entity that you cannot sensibly hoover up in a music function. And if you do something appalling, like letting oo inject "\\once \\override " into the input stream, it's very likely that it will break down in more complex uses than when just writing it into immediate code. > Help would be much appreciated. -- David Kastrup
