Re: macro for \once\override

[David Kastrup]

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

[Wols Lists]

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]

>> 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

[David Kastrup]

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: lilyglyphs not found in ubuntu packages 20.04

[bart deruyter]

Thanks for the update, I'll look into how I can change my document so it
uses lyluatex only. I used lyluatex to include complete scores in my
document, not for single musical signs, for that I used lilyglyphs.
Actually I'm considering to drop the latex road and switch to libreoffice,
for one big important reason: epub, and I need the epub format because of
the pandemic. I expect more Covid-19 related shutdowns of the schools I
work for, and my students use mobile devices very often. On these pdf's
are often not good, they don't scale good, epub does.

There is one important reason to keep lilyglyphs: compatibility with older
documents.
If I get what I need from lyluatex it's OK for me personally to drop
support for it, I haven't used it that often, I can handle fixing that, but
I doubt I'm the only one having documents using lilyglyphs.
I do revisit older files too and when my pdf's fail to compile because of
issues like these, needing to update something urgently, I think everybody
can agree that is not a very happy moment.
I was lucky it was not urgent. I really can't believe I'm the only one
having used lilyglyphs, so I'm afraid, dropping support for it all together
will result in many 'not very happy moments'.

grtz,
Bart
https://esmiltania.be
On Twitter 
On Google+ 


Op vr 28 aug. 2020 om 22:06 schreef Urs Liska :

> Hi Bart,
>
> thanks for reminding.
>
> Am Freitag, den 28.08.2020, 21:20 +0200 schrieb bart deruyter:
>
> Hi all,
>
> I would need to start working on my project again, using luatex, lilypond,
> lyluatex and lilyglyphs. But lilyglyphs appears to be missing from the
> ubuntu packages. This summer I upgraded to 20.04 though, and I found out to
> my surprise, lilyglyphs is missing. It is present in 'eoan' though.
>
> I already contacted the developer but only heard from him it is missing
> indeed and he did not know why either.
> Maybe someone here knows what has been going on.
>
>
> I asked on the texlive mailing list, and I got an answer, but I didn't
> manage following through
>
> Am Freitag, den 03.07.2020, 07:41 +0900 schrieb Norbert Preining:
>
> > Hi Urs,
> >
> >
> >
>
> > > Someone posted an issue that lilyglyphs.sty seems to be missing in
> > > TeX
> > > Live after updating to Ubuntu 20.04.
>
> >
> >
> > And in Debian. Because it depends on Python2 the last time I checked,
> >
> > and Python2 programs are not acceptable anymore in Debian and Ubuntu:
> >
> >
> >
> > From my Debian package building config file (ignore the syntax
> > around)
> >
> > # python3 purge - blacklist all packages that don't have py3
> > support
> >
> > blacklist;tpm;ebong;*
> >
> > blacklist;tpm;de-macro;*
> >
> > blacklist;tpm;lilyglyphs;*
> >
> > blacklist;tpm;pygmentex;*
> >
> > blacklist;tpm;sympytexpackage;*
> >
> >
> >
> > Update to Python3 version of the scripts is necessary.
>
>
> So the workaround would be to either update the helper scripts to Python 3
> or to drop these scripts. Off the top of my head I don't know how important
> these scripts actually are or how complex it would be to update them.
>
> They are used to create sets of new notation elements. IIRC.
> My personal gut feeling would be to drop support for lilyglyphs altogether
> because lyluatex can do everything lilyglyphs can, and better - i.e.
> without the need for pre-compiled PDFs. But - and that's a big but - the
> advantage of lilyglyphs is that it doesn't need to run LilyPond. *I* will
> always have LilyPond around, but for a general audience this would be a
> major limitation, I think.
>
> Opinions?
>
> Urs
>
> https://esmiltania.be
> On Twitter 
> On Google+ 
>
>

Re: macro for \once\override

[David Kastrup]

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

[Aaron Hill]

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

[Aaron Hill]

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

[Aaron Hill]

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: lilyglyphs not found in ubuntu packages 20.04

[Urs Liska]

Am Samstag, den 29.08.2020, 14:14 +0200 schrieb bart deruyter:
> Thanks for the update, I'll look into how I can change my document so
> it uses lyluatex only. I used lyluatex to include complete scores in
> my document, not for single musical signs, for that I used
> lilyglyphs. 

That's the idea, yes.
A workaround is to use lyluatex with insert=bare-inline, which includes
the music without a staff.
The significant advantage of this approach is that it doesn't have to
choose between Emmentaler glyphs and composed music.
> Actually I'm considering to drop the latex road and switch to
> libreoffice, for one big important reason: epub, and I need the epub
> format because of the pandemic. I expect more Covid-19 related
> shutdowns of the schools I work for, and my students use mobile
> devices very often. On these pdf's are often not good, they don't
> scale good, epub does.
> 
> There is one important reason to keep lilyglyphs: compatibility with
> older documents. 

Indeed. I would prefer keeping lilyglyphs available. But I'm afraid
there are issues beyond the Python dependency (which shouldn't be too
complicated after all). I had started fiddling around with a LuaLaTeX-
only version making use of new functionality, and IIRC I got stuck with
various issues. Maybe the best way to go forward would be to reset
lilyglyphs to the last released version and simply update the Python
stuff ...
I hope to find the time to look inzto that.
Urs
> If I get what I need from lyluatex it's OK for me personally to drop
> support for it, I haven't used it that often, I can handle fixing
> that, but I doubt I'm the only one having documents using
> lilyglyphs. 
> I do revisit older files too and when my pdf's fail to compile
> because of issues like these, needing to update something urgently, I
> think everybody can agree that is not a very happy moment.
> I was lucky it was not urgent. I really can't believe I'm the only
> one having used lilyglyphs, so I'm afraid, dropping support for it
> all together will result in many 'not very happy moments'.
> 
> grtz,
> Bart
> https://esmiltania.be
> On Twitter
> On Google+
> 
> 
> Op vr 28 aug. 2020 om 22:06 schreef Urs Liska 
> :
> > Hi Bart,
> > thanks for reminding.
> > Am Freitag, den 28.08.2020, 21:20 +0200 schrieb bart deruyter:
> > > Hi all,
> > > I would need to start working on my project again, using luatex,
> > > lilypond, lyluatex and lilyglyphs. But lilyglyphs appears to be
> > > missing from the ubuntu packages. This summer I upgraded to 20.04
> > > though, and I found out to my surprise, lilyglyphs is missing. It
> > > is present in 'eoan' though.
> > > 
> > > I already contacted the developer but only heard from him it is
> > > missing indeed and he did not know why either.
> > > Maybe someone here knows what has been going on.
> > 
> > I asked on the texlive mailing list, and I got an answer, but I
> > didn't manage following through
> > Am Freitag, den 03.07.2020, 07:41 +0900 schrieb Norbert Preining:
> > > > Hi Urs,
> > > > 
> > > > 
> > > > 
> > > > > > Someone posted an issue that lilyglyphs.sty seems to be
> > > > missing in
> > > > > > TeX
> > > > > > Live after updating to Ubuntu 20.04.
> > > > 
> > > > 
> > > > And in Debian. Because it depends on Python2 the last time I
> > > checked,
> > > > 
> > > > and Python2 programs are not acceptable anymore in Debian and
> > > Ubuntu:
> > > > 
> > > > 
> > > > 
> > > > From my Debian package building config file (ignore the syntax
> > > > around)
> > > > 
> > > > # python3 purge - blacklist all packages that don't
> > > have py3
> > > > support
> > > > 
> > > > blacklist;tpm;ebong;*
> > > > 
> > > > blacklist;tpm;de-macro;*
> > > > 
> > > > blacklist;tpm;lilyglyphs;*
> > > > 
> > > > blacklist;tpm;pygmentex;*
> > > > 
> > > > blacklist;tpm;sympytexpackage;*
> > > > 
> > > > 
> > > > 
> > > > Update to Python3 version of the scripts is necessary.
> > 
> > So the workaround would be to either update the helper scripts to
> > Python 3 or to drop these scripts. Off the top of my head I don't
> > know how important these scripts actually are or how complex it
> > would be to update them.
> > They are used to create sets of new notation elements. IIRC.My
> > personal gut feeling would be to drop support for lilyglyphs
> > altogether because lyluatex can do everything lilyglyphs can, and
> > better - i.e. without the need for pre-compiled PDFs. But - and
> > that's a big but - the advantage of lilyglyphs is that it doesn't
> > need to run LilyPond. *I* will always have LilyPond around, but for
> > a general audience this would be a major limitation, I think.
> > Opinions?
> > Urs
> > > https://esmiltania.be
> > > On Twitter
> > > On Google+
> > > 

Re: macro for \once\override

[David Kastrup]

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

[David Kastrup]

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]

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

[Werner LEMBERG]

> \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

[Aaron Hill]

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

Mailserver problem?

[John Helly]

Aloha.

There seems to be something wrong with the lilypond mailserver.  I'm
getting 6 copies (or 3 depending on how you count).  Is anyone else
experiencing this?   It's been going on for months, I just haven't
bothered complaining.

J.

On 8/28/20 22:17, Werner LEMBERG wrote:
>> 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
>
>

-- 

University of Hawaii, Maui College / Mobile 760.840.8660

Re: macro for \once\override

[David Kastrup]

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

[Aaron Hill]

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