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 > >