Re: Changes to Notename - lost some functionality
Hello and thank you very much for your input on this topic. I will try to follow the suggestions and implement my own procedure for the note names. I'll report back if I have success or new questions. Again, thank you very much!
Re: Changes to Notename - lost some functionality
> There's may be one extra paren in there because it threw a syntax error. Yes, sorry. > Is that a proper fix, or is something else wrong? I wouldn't call it a “proper” fix because it's a bit too dependent on details that can easily change (specifically, whether the default `NoteName` text is a markup that `markup->string` works well on). That's why I recommend `noteNameFunction` instead, it's also simpler. signature.asc Description: This is a digitally signed message part
Re: Changes to Notename - lost some functionality
On Wed, 2023-12-13 at 21:29 +0100, Jean Abou Samra wrote: > The quick fix here is to change > > (let* ((default-name (ly:grob-property grob 'text))) > to > > (let* ((default-name (markup->string (ly:grob-property grob 'text > > in order to first get an approximate string representation of that > markup that corresponds to the keys in your alist. There's may be one extra paren in there because it threw a syntax error. I removed one paren and it seems to work: germanNoteNames = #(lambda (grob) (let* ((default-name (markup->string (ly:grob-property grob 'text))) (new-name (assoc-get default-name newnames))) (ly:grob-set-property! grob 'text new-name) (ly:text-interface::print grob))) Tested on the mwe I made earlier today. Is that a proper fix, or is something else wrong?
Re: Changes to Notename - lost some functionality
This code is too big for me to digest it, but the basic problem is that
```
(let* ((default-name (ly:grob-property grob 'text))
(new-name (assoc-get default-name newnames)))
```
is doing a lookup in your `newnames` alist with the value of `text` as the key.
In more recent versions, `text` is not a string but a full markup, which you
can see if you add `(display default-name)`. So the lookup fails, `assoc-get`
returns false (`#f`), and you set the grob's text to false, which leads to a
warning because false isn't a markup.
The quick fix here is to change
```
(let* ((default-name (ly:grob-property grob 'text)))
```
to
```
(let* ((default-name (markup->string (ly:grob-property grob 'text
```
in order to first get an approximate string representation of that markup that
corresponds to the keys in your alist.
But instead of this fragile method of changing note names, it would be a lot
better to write a custom `noteNameFunction`, e.g.,
```
\version "2.24.2"
\new NoteNames {
\set noteNameFunction =
#(lambda (pitch context)
;; Write logic to compute the note name from `pitch` as a markup.
"TODO")
c' d' e'
}
```
signature.asc
Description: This is a digitally signed message part
Re: Changes to Notename - lost some functionality
Stefano Antonelli wrote:
A good place to start is a minimum working example. I can't help debug
this, but I put together a minimum working example that shows the
problem. Maybe someone with better scheme can spot the problem.
With liilypond v2.20 there is no issue. With lilypond v2.23.3
Preprocessing graphical objects...
programming error: Trying to interpret a non-markup object: #f
continuing, cross fingers
programming error: Trying to interpret a non-markup object: #f
continuing, cross fingers
programming error: Trying to interpret a non-markup object: #f
continuing, cross fingers
programming error: Trying to interpret a non-markup object: #f
continuing, cross fingers
Finding the ideal number of pages...
newnames =
#`(
("c" . "cee")
("d" . "dee")
("e" . "eee")
("f" . "fff")
)
With lilypond v2.20 there is no issue.
With lilypond v2.21.1, the names are missing
(and the 4 errors are reported differently)
warning: no \version statement found, please add
\version "2.21.1"
for future compatibility
Interpreting music...
Preprocessing graphical objects...
programming error: Object is not a markup.
continuing, cross fingers
programming error: Object is not a markup.
continuing, cross fingers
programming error: Object is not a markup.
continuing, cross fingers
programming error: Object is not a markup.
continuing, cross fingers
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `./tmp-lilypond-UX8ggy'...
Converting to `2.pdf'...
Deleting `./tmp-lilypond-UX8ggy'...
This object should be a markup: #f
This object should be a markup: #f
This object should be a markup: #f
This object should be a markup: #f
Success: compilation successfully completed
Cheers,
Robin
Re: Changes to Notename - lost some functionality
On Wed, 2023-12-13 at 11:12 +0100, Sebastian Käppler wrote:
> Any help on this would be appreciated, I'm a bit lost now where to
> start.
A good place to start is a minimum working example. I can't help debug
this, but I put together a minimum working example that shows the
problem. Maybe someone with better scheme can spot the problem.
With liilypond v2.20 there is no issue. With lilypond v2.23.3
Preprocessing graphical objects...
programming error: Trying to interpret a non-markup object: #f
continuing, cross fingers
programming error: Trying to interpret a non-markup object: #f
continuing, cross fingers
programming error: Trying to interpret a non-markup object: #f
continuing, cross fingers
programming error: Trying to interpret a non-markup object: #f
continuing, cross fingers
Finding the ideal number of pages...
newnames =
#`(
("c" . "cee")
("d" . "dee")
("e" . "eee")
("f" . "fff")
)
germanNoteNames =
#(lambda (grob)
(let* ((default-name (ly:grob-property grob 'text))
(new-name (assoc-get default-name newnames)))
(ly:grob-set-property! grob 'text new-name)
(ly:text-interface::print grob)))
melody = { c d e f }
\score {
<<
\new Staff { \melody }
\new NoteNames {
\override NoteName.stencil = #germanNoteNames
\melody
}
>>
\layout {}
}
