[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Setting up classical guitar fingerings

From: Luca Fascione
Subject: Re: Setting up classical guitar fingerings
Date: Sun, 6 Mar 2022 20:02:21 +0100

Hi Valentin,
thanks for the super prompt reply!

On Sun, Mar 6, 2022 at 5:34 PM Valentin Petzel <> wrote:

> So instead of doing the assoc-set! you might want to do something like
> (ly:grob-set-property! grob 'details `((beamed-lengths . ,stem-bmlgths)
>       . ,detls))

For my edification, I'll talk for a moment about the differences between
your code and this other attempt
(which also seems to work, I had gotten myself mixed up with what copy-list
does, and I had copy-list here, which isn't deep enough):

(ly:grob-set-property! grob 'details (assoc-set! (copy-tree detls)
'beamed-lengths stem-bmlgths))

could you set me straight, if needed?

 - Your code "just prepends" a new cell with a key we're interested in
right in front of the old content (with which shares structure)
 - It relies on lists being ordered, and all access to alists being a
straight linear scan front-to-back (point being: 'beamed-lengths appears
twice and we use "first one wins" to deal with the repeated key)
 - Your way is probably more economical than mine in that mine copies all
entries in the list, while yours just prepends one onto a list that is
otherwise shared
 - Your quasiquote segment produces exactly the same output as (append
'(('beamed-lengths . stem-bmlgths)) detls)

This solution of yours does not do any collision checking, which will make
> all
> Stems longer as long as there is a Fingering on the Stem. You might want
> to
> try something similar to what I did before to get some sort of collision
> checking in.

Yes definitely, I was just illustrating the problem. I'll definitely need
much more careful code than this in the final solution.
However, just so I don't overlook some aspect, could you give me a sense of
what collisions worry you?
One of the things I had found attractive in messing with beamed-lengths is
that the rest of the layout engine stays in place and operative.
So that line-to-line and beams-to-spanner things are handled by the rest of
lilypond as it stands today now?
(This was my reasoning also in trying to avoid xxx-offset stuff, because if
I understand right it happens post conflict-resolution
which seems not what I need). Am I not thinking this right?

Many thanks

reply via email to

[Prev in Thread] Current Thread [Next in Thread]