Re: Question on commit c478396f Move all doc building logic to Documentation/GNUmakefile

[John Wheeler]

On 9/29/2021 6:13 PM, Jean Abou Samra wrote:
> Le 30/09/2021 à 01:11, John Wheeler a écrit :
> > I must be the one exception to "nobody uses this", I appreciate the 
> > "good luck" wish.
>
> Curious: what is your use case?
I originally started down this path because I wanted to create a method 
to typeset tablature for a hammered dulcimer.

The instrument I play can be modeled as 16 courses with 3 striking 
locations per course, each location with an assigned pitch. The pitches 
are not consistently harmonically related across the course.  A fair 
number of pitches are available in multiple locations. I wrote a program 
that accepts a simple lilypond input and suggests an optimal hammering 
pattern, optimal from the point of minimizing difficult reaches, crossed 
hands and such, but the output is currently simply a stream of triplets: 
(right/left hand, course, location).

I used lilypond input format for my program so I could verify the 
printed LilyPond output to the original music I wanted to optimize.  To 
me it seemed it should be a small leap to substitute my optimization 
algorithm for the string/fret calculation in LilyPond and simply typeset 
the suggested hammering pattern.

While I find a wealth of highly detailed information in the 
documentation and can see how much of it is created directly from the 
code, I am still working to gain the understanding of the program flow 
to allow me to realize my goal.  This led me to look at the lexer, 
parser, ... looking for that understanding.

In jest I add: reading the code is a lot of fun, but I miss the 
programmer's guide to the lilypond language and it's libraries.

Do you think there is enough interest in programming in lilypond in the 
community to create one? Maybe even just a complete introduction to the 
concepts and program flow with pointers to the rest of the documentation 
for the details?

I am motivated to offer my help.

John Wheeler