Hello Luca, the problem here is that assoc-set! MIGHT change the original alist (but it doesn’t have to). So it is adviced to always combine assoc-set! with an assignment. In this case assoc-set! changes the original alist.
This alist is created once during definition of grob-defaults, so each single
Stem-Grob shares this alist! This means that if assoc-set! changes the
original alist it changes this alist for all Stem grobs, which results in the
beamed-lengths value exploding. If you look at your debug output you’ll see
that with each encountered Stem the value increases!
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))
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.
Cheers,
Valentin
Am Sonntag, 6. März 2022, 16:25:32 CET schrieb Luca Fascione:
> So, I feel like I'm making progress here.
> However I am now at a different stumble, I feel I'm misunderstanding the
> referencing patterns of the grob properties somewhere.
>
> You'll see in the attached pdf that all the stems are very long.
> Here's what's going on: I'm experimenting with pushing the beaming out a
> little when there is fingering on the note head.
> However my tweak to the steam lengths is applied to all stems in the piece,
> _each time_, instead of once per note.
>
> More in detail:
> Riffing on Valentin's idea, I reversed the behaviour of the guitar
> fingering engraver, and now when there is a fingering,
> I attach a reference it to the stem's 'details alist. This is then picked
> up in a new Stem.before-line-breaking callback:
> my idea was: if there is a fingering instruction attached to the grob
> (being a stem), simply do a += 1 on the values of the beamed-lengths list.
> (obv this "+1" will need to take into account positioning and size of the
> fingering notation, in real life, but for a first test I thought it'd be a
> start).
>
> However I'm running into a problem where I seem to be modifying the setup
> for the 'details of _all_ the Stem grobs in the sheet,
> which means that my intention of adding 0.25 staff spaces (for the sake of
> the example) to the one stem at hand to the callback,
> is turning into this monster where _all_ stems get added 0.25 times
> (fingering counts in the whole piece) . And that's a bit much :-)
>
> I've tried various approaches to copying the dtls variable with (list-copy
> dtls) and a couple things like that, but I wasn't able to
> affect the final result at all.
>
> Could anybody help me understand what's going on please?
>
> Many thanks
> Luca
>
> On Sat, Mar 5, 2022 at 6:27 PM Luca Fascione <l.fasci...@gmail.com> wrote:
> > Thanks Valentin, this is useful.
> >
> > Sounds like I'll be back with questions :-)
> >
> > L
> >
> > On Sat, Mar 5, 2022 at 5:46 PM Valentin Petzel <valen...@petzel.at> wrote:
> >> Hello Luca,
> >>
> >> the design of Lilypond inherently implies that there is no clear border
> >> between users and developers. Lilypond has an user interface, which is
> >> covered
> >> more or less in the docs, an extended interface in scheme, which is not
> >> documented that extensively, and the C++ code that works behind this,
> >> which
> >> barely documented. This means that in the Lilypond-verse it is useful to
> >> speak
> >> Lilypond, Scheme, C++ (and maybe Python), with basic users sitting at the
> >> Lilypond end and developers sitting at the C++ side, with the scheme
> >> stuff
> >> hanging in between.
> >>
> >> This means that you as a user can turn into a developer of some sort and
> >> write
> >> code into you Lilypond score that drastically changes how Lilypond does
> >> things
> >> (which is kind of cool). But if you are trying to do this you will often
> >> find
> >> yourself in the situation that you do not know how certain things are
> >> handled
> >> and the docs offer very little support.
> >>
> >> Thus I find it easier to look directly into the code. Lilypond has three
> >> directories of relevant code in it’s source directory:
> >>
> >> → Ly: Which contains code in Lilypond-Language, mostly setting up the
> >> defaults
> >> and music functions and such
> >> → scm: Which contains code in Scheme and contains a decent bit of
> >> Lilypond’s
> >> functionality, at least that part which does not matter that much
> >> performance-
> >> wise
> >> → lily: Which contains the c++-Code, which is the major part of the core
> >> functionality.
> >>
> >> If I’m looking for things I usually grep for these things in these
> >> directories. Eventually you’ll have a good idea where what is sitting.
> >> For
> >> example a scheme function like ly:somethingA::somethingB is usually a
> >> callback to the c++ class somethingA, method somethingB.
> >>
> >> In scm you also have the definitions of the default grobs, so if you want
> >> to
> >> know what exact properties a grob has, you can look in define-grobs.scm.
> >> And
> >> similar stuff.
> >>
> >> And if you encounter something you really do not understand, ask the
> >> list.
> >> We’ve got some really marvellous people here who appear to know about
> >> everything you might want to know about Lilypond.
> >>
> >> Cheers,
> >> Valentin
> >>
> >> Am Samstag, 5. März 2022, 17:05:22 CET schrieb Luca Fascione:
> >> > I took a "brief" detour where I went and learned a bit about scheme
> >> > ==== Interlude
> >> > FWIW, I don't recall seeing this reference in your resources about
> >>
> >> learning
> >>
> >> > Scheme, so I'll leave a comment here:
> >> >
> >> > Paul Wilson (professor at UTexas, Austin) wrote some notes on Scheme
> >>
> >> approx
> >>
> >> > in 1996,
> >> > which I thought were extremely well conceived and clear. Certainly more
> >>
> >> to
> >>
> >> > the point that sicp
> >> > (which is a very interesting approach if you're learning Lisp and sw
> >> > engineering at the same time,
> >> > but I found did not make good use of my pre-acquired understanding of
> >>
> >> the
> >>
> >> > field, and just slowed me down).
> >> > I found the book very easy to follow and I loved that he teaches Scheme
> >>
> >> by
> >>
> >> > showing a series of gradually
> >> > more accurate implementations of scheme, partially in scheme. Also it
> >> > teaches Scheme in a way that is
> >> > very compatible with other programming languages, that makes it really
> >>
> >> easy
> >>
> >> > to keep it straight in one's head
> >> > what is new information or different vs what is just the same.
> >> > Unfortunately the several available copies online were never completed,
> >>
> >> so
> >>
> >> > there are several little bugs,
> >> > missing cross-references and other polish-grade features missing. But I
> >> > thought the juice of the book is certainly excellent.
> >> >
> >> > It seems Prof Wilson has since retired, and various threads on the
> >>
> >> internet
> >>
> >> > indicate folks are unable to reach him.
> >> > He seems to have done work in the 90's about garbage collection in
> >> > languages.
> >> > ====
> >> >
> >> > Now that I can follow Scheme source with a certain level of confidence,
> >>
> >> I
> >>
> >> > went back to work on the fingering task,
> >> > and re-read Valentin's code. And thanks again kind sir.
> >> >
> >> > I was thinking again about the idea of instead of pushing the fingering
> >> > "down" (say we're doing \stemsUp) because the beams are too low,
> >> > to push the beams "up" to leave space for the fingering. And I played
> >>
> >> for a
> >>
> >> > second with Stem.details.beamed-lengths
> >> > (using an override in the .ly file, inbetween the notes) which seems to
> >> > achieve what we need.
> >> > So in order to automate that, I'd like to understand better the
> >>
> >> execution
> >>
> >> > of before-line-break and after-line-break callbacks.
> >> > I'm thinking that I could set up the fingering position in
> >> > Fingering.before-line-break and alter the stem length
> >> > (details.beamed-lengths, being my current thinking) in
> >> > Stem.before-line-break.
> >> >
> >> > Really the question is a meta-question: I can certainly hack at this
> >> > and
> >> > see what happens, but also how I do help myself learn this better:
> >> > where is the code that handles this stuff and how do I trace the
> >>
> >> sequence
> >>
> >> > of events around this stuff?
> >> >
> >> > I'm looking for a couple one-liner breadcrumbs such as "this section of
> >>
> >> the
> >>
> >> > docs" (which I tried to read without much success),
> >> > "grep <this> and <that> in the source", it's all in "scm/<couple
> >> > filenames>". Vague pointers like that are hopefully all I'll need.
> >> >
> >> > Many thanks,
> >> > Luca
> >> >
> >> > On Mon, Feb 21, 2022 at 6:49 PM Luca Fascione <l.fasci...@gmail.com>
> >>
> >> wrote:
> >> > > Yes exactly, because of how our finger to note relation works, the
> >> > > enhancement in readability with the indication right at the head is
> >> > > enormous.
> >> > >
> >> > > L
> >> > >
> >> > > On Mon, 21 Feb 2022, 18:16 Valentin Petzel, <valen...@petzel.at>
> >>
> >> wrote:
> >> > >> Sure. I suppose for a guitar person having stacked fingerings on top
> >> > >> would be
> >> > >> rather confusing, as there is no monotonic relating between finger
> >>
> >> and
> >>
> >> > >> pitch.
> >> > >> As such I suppose guitar people would want to use fingerings with
> >>
> >> left or
> >>
> >> > >> right
> >> > >> orientations in chords anyway.
> >> > >>
> >> > >> Cheers,
> >> > >> Valentin
> >> > >>
> >> > >> Am Montag, 21. Februar 2022, 17:47:58 CET schrieb Luca Fascione:
> >> > >> > I suspect we might be saying the same thing, Valentin?
> >> > >> >
> >> > >> > I was saying infix can be a bit awkward if you want 'pianist'
> >> > >> > chord
> >> > >> > fingering (just a stack of numbers above or below), and that your
> >> > >>
> >> > >> original
> >> > >>
> >> > >> > <c d g>-1-2-3 reads quite nicely (as in: it's easy to see in your
> >>
> >> head
> >>
> >> > >> what
> >> > >>
> >> > >> > you will get in the engraving just by looking at the source). So a
> >> > >>
> >> > >> keyboard
> >> > >>
> >> > >> > person wouldn't want to use infix, I don't think
> >> > >> >
> >> > >> > Whereas a guitar person might find it more attractive to use <c-1
> >>
> >> d-2
> >>
> >> > >> g-3>
> >> > >>
> >> > >> > because it's easier to keep it straight in your head what fingers
> >>
> >> you
> >>
> >> > >> use
> >> > >>
> >> > >> > on what note that way
> >> > >> >
> >> > >> > L
> >> > >> >
> >> > >> > On Mon, Feb 21, 2022 at 5:42 PM Valentin Petzel <
> >>
> >> valen...@petzel.at>
> >>
> >> > >> wrote:
> >> > >> > > No, not nescessarily. If we want all Fingerings on top or below
> >>
> >> there
> >>
> >> > >> is
> >> > >>
> >> > >> > > no real benefit of doing the chord thing. In fact doing that
> >>
> >> leads to
> >>
> >> > >> the
> >> > >>
> >> > >> > > exact same issue of the fingering for d being next to the other
> >>
> >> ones.
> >>
> >> > >> > > Cheers,
> >> > >> > > Valentin
> >> > >> > >
> >> > >> > > 21.02.2022 12:38:40 Luca Fascione <l.fasci...@gmail.com>:
> >> > >> > >
> >> > >> > > But wouldn't you finger that as <c-1 d-2 g-3>? (Didn't check the
> >> > >>
> >> > >> number,
> >> > >>
> >> > >> > > I'm just meaning going infix vs postfix)
> >> > >> > >
> >> > >> > > I can see that this idea of mine does have issues for fingering
> >>
> >> your
> >>
> >> > >> way
> >> > >>
> >> > >> > > around (which seems to me it's more of a fingering atop thing,
> >>
> >> like
> >>
> >> > >> you
> >> > >>
> >> > >> > > would have in a keyboard score)
> >> > >> > >
> >> > >> > > L
> >> > >> > >
> >> > >> > > On Mon, 21 Feb 2022, 12:32 Valentin Petzel, <valen...@petzel.at>
> >> > >>
> >> > >> wrote:
> >> > >> > >> Hello Luca,
> >> > >> > >>
> >> > >> > >> changing the X-parent to the NoteHead would mean that we are
> >> > >>
> >> > >> aligning the
> >> > >>
> >> > >> > >> Fingering horizontally wrt. the NoteHead instead of the whole
> >> > >>
> >> > >> NoteColumn.
> >> > >>
> >> > >> > >> This
> >> > >> > >> would then mean that if for example due to some chord some note
> >> > >>
> >> > >> heads are
> >> > >>
> >> > >> > >> on
> >> > >> > >> the other side of the Stem the alignment of something like <c d
> >> > >>
> >> > >> g>-1-2-3
> >> > >>
> >> > >> > >> would
> >> > >> > >> change (disregarding that it wouldn’t even be clear what note
> >>
> >> head
> >>
> >> > >> > >> to
> >> > >> > >> use).
> >> > >> > >>
> >> > >> > >> Cheers,
> >> > >> > >> Valentin
> >> > >> > >>
> >> > >> > >> Am Montag, 21. Februar 2022, 09:19:30 CET schrieb Luca
Fascione:
> >> > >> > >> > Hi Thomas,
> >> > >> > >> > thanks for your comment, this helps me refine my
> >>
> >> understanding of
> >>
> >> > >> > >> what's
> >> > >> > >>
> >> > >> > >> > going on.
> >> > >> > >> >
> >> > >> > >> > At the same time, while I do see that for other articulations
> >> > >>
> >> > >> (fermata,
> >> > >>
> >> > >> > >> > appoggiato) this parenting scheme works very well,
> >> > >> > >> > I remain wondering whether for the style of layout of the
> >> > >> > >> > fingering
> >> > >> > >> > indications that I am after, the appropriate thing to do
> >>
> >> could be
> >>
> >> > >> to
> >> > >>
> >> > >> > >> change
> >> > >> > >>
> >> > >> > >> > the parenting altogether.
> >> > >> > >> >
> >> > >> > >> > If we look at chord for a second, I see the <one-note-chord>
> >>
> >> thing
> >>
> >> > >> as a
> >> > >>
> >> > >> > >> > trick because to me even for proper chords the whole
> >> > >>
> >> > >> FingeringColumn
> >> > >>
> >> > >> > >> idea
> >> > >> > >>
> >> > >> > >> > is also a weird concept: imagine you're in say C major, and
> >>
> >> you're
> >>
> >> > >> > >> laying
> >> > >> > >>
> >> > >> > >> > out fingering on the left of a chord like Fm <f aes c'>: I'm
> >>
> >> very
> >>
> >> > >> > >> unclear
> >> > >> > >>
> >> > >> > >> > whether the most readable solution is to have the fingerings
> >> > >>
> >> > >> stacked
> >> > >>
> >> > >> > >> one
> >> > >> > >>
> >> > >> > >> > atop each other in a column (thereby more distant from f and
> >> > >> > >> > c
> >> > >>
> >> > >> because
> >> > >>
> >> > >> > >> of
> >> > >> > >>
> >> > >> > >> > the intervening flat on the aes) or if instead the fingerings
> >>
> >> on f
> >>
> >> > >> and
> >> > >>
> >> > >> > >> c
> >> > >> > >>
> >> > >> > >> > should be set tighter to their corresponding note heads and
> >>
> >> just
> >>
> >> > >> the
> >> > >>
> >> > >> > >> aes
> >> > >> > >>
> >> > >> > >> > fingering be displaced left horizontally, to allow for the
> >>
> >> flat. I
> >>
> >> > >> > >> would
> >> > >> > >>
> >> > >> > >> > like to experiment with various possibilities there,
> >>
> >> visually. I
> >>
> >> > >> > >> suppose
> >> > >> > >>
> >> > >> > >> > you could still displace horizontally inside the column, and
> >>
> >> then
> >>
> >> > >> push
> >> > >>
> >> > >> > >> it
> >> > >> > >>
> >> > >> > >> > all inwards closer to the chord even if the bboxes will
> >>
> >> overlap a
> >>
> >> > >> > >> bit... I
> >> > >> > >>
> >> > >> > >> > anticipate issues such as making sure the fingering for c'
> >>
> >> doesn't
> >>
> >> > >> > >> > interfer with the ascender on the flat glyph, also.
> >> > >> > >> >
> >> > >> > >> > Which brings me to a question: what consequence would it have
> >>
> >> to
> >>
> >> > >> > >> replace
> >> > >> > >>
> >> > >> > >> > the X-parent and Y-parent of the fingering to be the NoteHead
> >> > >>
> >> > >> instead?
> >> > >>
> >> > >> > >> > (I guess there will be a need to deal with the accidentals at
> >>
> >> a
> >>
> >> > >> > >> minimum)
> >> > >> > >>
> >> > >> > >> > And also: how would I go at discovering these consequences
> >>
> >> without
> >>
> >> > >> > >> using
> >> > >> > >>
> >> > >> > >> > too much of you guys' time?
> >> > >> > >> >
> >> > >> > >> > Thanks again,
> >> > >> > >> > Luca
> >> > >> > >> >
> >> > >> > >> > On Mon, Feb 21, 2022 at 1:22 AM Thomas Morley
> >> > >> > >> > <thomasmorle...@gmail.com>
> >> > >> > >> >
> >> > >> > >> > wrote:
> >> > >> > >> > > Am So., 20. Feb. 2022 um 22:41 Uhr schrieb Luca Fascione <
> >> > >> > >> > >
> >> > >> > >> > > l.fasci...@gmail.com>:
> >> > >> > >> > > > a) I'm looking for a way to get the fingerings where I
> >>
> >> want
> >>
> >> > >> them
> >> > >>
> >> > >> > >> > > > without
> >> > >> > >> > > >
> >> > >> > >> > > > using one-note-chord tricks
> >> > >> > >> > >
> >> > >> > >> > > Well, for Fingerings not in chord, like b-1 or <b dis'>-2-1
> >> > >>
> >> > >> X-parent
> >> > >>
> >> > >> > >> > > is NoteColumn _not_ NoteHead, Y-parent is
> >>
> >> VerticalAxisGroup.
> >>
> >> > >> > >> > > There is no direct way from NoteHead to Fingering and vice
> >> > >> > >> > > versa.
> >> > >> > >> > >
> >> > >> > >> > > Thus putting Fingering in-chord is unavoidable, imho, even
> >>
> >> for
> >>
> >> > >> single
> >> > >>
> >> > >> > >> > > notes.
> >> > >> > >> > > It is _not_ a trick, but a requirement.
> >> > >> > >> > >
> >> > >> > >> > > Furthermore, you say you set music for classical guitar,
> >>
> >> then
> >>
> >> > >> chords
> >> > >>
> >> > >> > >> > > will happen anyway, although not in your example.
> >> > >> > >> > > Please note, as soon as more than one in-chord Fingering is
> >> > >>
> >> > >> present a
> >> > >>
> >> > >> > >> > > FingeringColumn is created. Which will make things even
> >> > >> > >> > > more
> >> > >> > >> > > complicated.
> >> > >> > >> > > See
> >> > >> > >> > > https://gitlab.com/lilypond/lilypond/-/issues/6125
> >> > >> > >> > > https://gitlab.com/lilypond/lilypond/-/merge_requests/732
> >> > >> > >> > >
> >> > >> > >> > > Sorry to be of not more help,
> >> > >> > >> > >
> >> > >> > >> > > Harm
signature.asc
Description: This is a digitally signed message part.
