Re: Setting up classical guitar fingerings

[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.fascione@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 <valentin@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.fascione@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, <valentin@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 <valentin@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.fascione@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, <valentin@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
> >> > >> > <thomasmorley65@gmail.com>
> >> > >> >
> >> > >> > wrote:
> >> > >> > > Am So., 20. Feb. 2022 um 22:41 Uhr schrieb Luca Fascione <
> >> > >> > >
> >> > >> > > l.fascione@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

fingering-tests-4.ly
Description: Binary data

fingering-tests-4.pdf
Description: Adobe PDF document