[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Updating alists (was: Tenuto marking too close to note)
From: |
Lukas-Fabian Moser |
Subject: |
Updating alists (was: Tenuto marking too close to note) |
Date: |
Thu, 30 Dec 2021 12:36:37 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 |
Hi Jean, (CCing devel because of the stuff below the asterisks)
Although this approach manipulates internal data structures of
LilyPond, it has the advantage of dealing with your issue at the root
and not causing side effects for other scripts. Unfortunately, this
approach does not work directly for the (still experimental) LilyPond
builds using Guile2.
Be mindful that assoc-set! is not guaranteed to
mutate its input. You're not the first one tripped
up by this API quirk :-)
It's much worse than that: It's not the first time _I've_ been tripped
up by this (previously it was with sort!). I'll just have to write 100
copies of
"The exclamation mark in something! does not mean the function is
guaranteed to make the desired change in-place."
on my wall.
But more seriously: Thanks! And also for advertising ice-9 match - it's
really a different coding style from the more commonly seen (if pair?
...) constructs.
* * *
Another question: With the (hopefully) upcoming changes in the
script-alist structure (using symbols instead of strings as keys), we're
quite close to being able to simply do
\version "2.23.6"
myScripts = \default-script-alist
myScripts.tenuto.padding = 5
\layout {
\context {
\Score
scriptDefinitions = #myScripts
}
}
{
a--
}
(One might also skip defining a new variable and instead change
default-script-alist directly, but it has to be re-read in a \layout
block anyway.)
But at the moment, this does not work because the changed key is not
being replaced in the alist but added at the beginning. If I see things
correctly, this is the remark about "not coalescing multiple overrides
of the same property" in nested_property_alist(...) in
ily/nested-property.cc.
Re-enabling the outcommented branch in that function (taking care to use
assoc_tail instead of assq_tail and correcting the order of arguments to
that call) basically works, but there's trouble ahead in the case where
one does
variable.entry = 15
variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all
which unfortunately is what happens if one \override's a nested property
given by a callback (e.g. VerticalAxisGroup.staff-staff-spacing), or worse
variable.entry = #'(some . pair)
variable.entry.first = #'i-ve-decided-i-want-a-sublist-after-all
since an entry that is a pair looks like the beginning of a sublist.
On the other hand, I would expect people who are using
Violin.I = { \someMusic }
Violin.I = { \someNewMusic }
would indeed like to be their first definition to actually be replaced
(even if using \Violin.I in a score happens to produce only the most
recent entry).
Thoughts?
Lukas
- Tenuto marking too close to note, Erika Pirnes, 2021/12/28
- Re: Tenuto marking too close to note, Vaughan McAlley, 2021/12/28
- Re: Tenuto marking too close to note, Werner LEMBERG, 2021/12/29
- Re: Tenuto marking too close to note, Lukas-Fabian Moser, 2021/12/29
- Re: Updating alists (was: Tenuto marking too close to note), Lukas-Fabian Moser, 2021/12/30
- Re: Updating alists (was: Tenuto marking too close to note), Jean Abou Samra, 2021/12/30
- Re: Updating alists, David Kastrup, 2021/12/30
- Re: Updating alists, David Kastrup, 2021/12/30