Re: lilypond-user Digest, Vol 218, Issue 4

[Flaming Hakama by Elaine]

>
>
>
> -- Forwarded message --
> From: Carl Sorensen 
> To: Kieren MacMillan , Christian Masser <
> christian.mas...@gmail.com>
> Cc: David Nalesnik , Carl Sorensen <
> carl.d.soren...@gmail.com>, Lilypond-User Mailing List <
> lilypond-user@gnu.org>, Peter Toye 
> Bcc:
> Date: Fri, 1 Jan 2021 20:35:54 +
> Subject: Re: A comment about the documentation
> This should be quite straightforward.
>
> Clone the repository from GitLab.
>
> Make your own branch.
>
> Search for the DOCME strings.
>
> Edit some set of the files.
>
> Make sure that LilyPond still builds.  And that make doc succeeds.
>
> Push a merge request to GitLab.
>
> Wait for the review process.
>
> Merge the merge request.
>
> The biggest problem will be that you are using a Mac, IIRC.  And that
> means you will need to build on the Mac.  I do it with a VM.  I have not
> had good success (nor have I tried very hard) with Docker containers.
>
> Perhaps Hans can help you do the build using MacPorts.
>
> I'm happy to answer any questions I can, although I'm probably not very
> useful at it right now.
>
> Thanks,
>
> Carl
>
>
> On 1/1/21, 1:07 PM, "Kieren MacMillan" 
> wrote:
>
> Hi all,
>
> > ...well, if at anytime someone wants to help out and give something
> back to Lilypond: there are 583 instances of "DOCME" in the result of that
> script. Looks like an extensive list of "simple" and well packaged tasks if
> one wants to give a try at participating.
>
> Anyone (Carl? David?) interested in, and available to, mentor me
> through whatever setup/process is required to contribute to the
> documentation? I’m assuming once that’s done, and I’m contributing
> documentation patches without requiring hand-holding, “levelling up” to
> contributing “real code” would be pretty



Actual leveling up would mean trying to build it on Mac.

For documentation, I would not even consider that, and rather run LilyDev
in a VM.

Re: A comment about the documentation

[Thomas Morley]

Am Fr., 1. Jan. 2021 um 23:25 Uhr schrieb Thomas Morley
:
>
> Am Fr., 1. Jan. 2021 um 20:24 Uhr schrieb David Nalesnik
> :
> >
> > Hi Harm,
> >
> > On Fri, Jan 1, 2021 at 12:44 PM Thomas Morley  
> > wrote:
> > >
> > > the above linked code catches none-public definitions as well, not sure 
> > > why...
> > > P.e. `split-at-predicate`
> > >
> > > Best wishes.
> > >   Harm
> >
> > Nice catch!
> >
> > This change should catch only the exported bindings:
> >
> > #(define (get-binding-list iface)
> >(ly:module->alist (resolve-interface iface)))
>
> If I'm not mistaken this _is_ already used in
> https://www.mail-archive.com/lilypond-user@gnu.org/msg100337.html
>
> Cheers,
>   Harm

I misread.
You changed resolve-module to resolve-interface
Now working as expected.

Thanks,
  Harm

Re: A comment about the documentation

[Thomas Morley]

Am Fr., 1. Jan. 2021 um 20:24 Uhr schrieb David Nalesnik
:
>
> Hi Harm,
>
> On Fri, Jan 1, 2021 at 12:44 PM Thomas Morley  
> wrote:
> >
> > the above linked code catches none-public definitions as well, not sure 
> > why...
> > P.e. `split-at-predicate`
> >
> > Best wishes.
> >   Harm
>
> Nice catch!
>
> This change should catch only the exported bindings:
>
> #(define (get-binding-list iface)
>(ly:module->alist (resolve-interface iface)))

If I'm not mistaken this _is_ already used in
https://www.mail-archive.com/lilypond-user@gnu.org/msg100337.html

Cheers,
  Harm

Re: A comment about the documentation

[Carl Sorensen]

This should be quite straightforward.

Clone the repository from GitLab.

Make your own branch.

Search for the DOCME strings.

Edit some set of the files.

Make sure that LilyPond still builds.  And that make doc succeeds.

Push a merge request to GitLab.

Wait for the review process.

Merge the merge request.

The biggest problem will be that you are using a Mac, IIRC.  And that means you 
will need to build on the Mac.  I do it with a VM.  I have not had good success 
(nor have I tried very hard) with Docker containers.

Perhaps Hans can help you do the build using MacPorts.

I'm happy to answer any questions I can, although I'm probably not very useful 
at it right now.

Thanks,

Carl



On 1/1/21, 1:07 PM, "Kieren MacMillan"  wrote:

Hi all,

> ...well, if at anytime someone wants to help out and give something back 
to Lilypond: there are 583 instances of "DOCME" in the result of that script. 
Looks like an extensive list of "simple" and well packaged tasks if one wants 
to give a try at participating.

Anyone (Carl? David?) interested in, and available to, mentor me through 
whatever setup/process is required to contribute to the documentation? I’m 
assuming once that’s done, and I’m contributing documentation patches without 
requiring hand-holding, “levelling up” to contributing “real code” would be 
pretty trivial.

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: A comment about the documentation

[Kieren MacMillan]

Hi all,

> ...well, if at anytime someone wants to help out and give something back to 
> Lilypond: there are 583 instances of "DOCME" in the result of that script. 
> Looks like an extensive list of "simple" and well packaged tasks if one wants 
> to give a try at participating.

Anyone (Carl? David?) interested in, and available to, mentor me through 
whatever setup/process is required to contribute to the documentation? I’m 
assuming once that’s done, and I’m contributing documentation patches without 
requiring hand-holding, “levelling up” to contributing “real code” would be 
pretty trivial.

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: A comment about the documentation

[David Nalesnik]

Hi Harm,

On Fri, Jan 1, 2021 at 12:44 PM Thomas Morley  wrote:
>
> the above linked code catches none-public definitions as well, not sure why...
> P.e. `split-at-predicate`
>
> Best wishes.
>   Harm

Nice catch!

This change should catch only the exported bindings:

#(define (get-binding-list iface)
   (ly:module->alist (resolve-interface iface)))

Best,
David

Re: A comment about the documentation

[Thomas Morley]

Am Fr., 1. Jan. 2021 um 18:19 Uhr schrieb David Nalesnik
:
>
> Hi Peter,
>
> On Fri, Jan 1, 2021 at 10:46 AM Peter Toye  wrote:
>>
>> Carl,
>
>
>>
>> [...]
>
>
>>
>> I hate to say it but I think the documentation is failing here, but can't 
>> see how to mend it easily. To start with, maybe a list of all the publicly 
>> available functions and their descriptions, but I suspect it would be far 
>> too long and need constant updating, which is not something that the LP 
>> documenters like for obvious reasons. Could it be mechanised?
>>
>> Best regards,
>>
>> Peter
>
>
> Here's something which will give you a list of all public Scheme functions 
> with whatever docstring is available in the source:
>
> https://www.mail-archive.com/lilypond-user@gnu.org/msg100337.html
>
> Hope this helps--
> David

Hi David,

the above linked code catches none-public definitions as well, not sure why...
P.e. `split-at-predicate`

Best wishes.
  Harm

Re: A comment about the documentation

[Christian Masser]

Hi David!

Thanks for that find!

...well, if at anytime someone wants to help out and give something back to
Lilypond: there are 583 instances of "DOCME" in the result of that script.
Looks like an extensive list of "simple" and well packaged tasks if one
wants to give a try at participating.

All the best
Christian

Am Fr., 1. Jan. 2021 um 18:19 Uhr schrieb David Nalesnik <
david.nales...@gmail.com>:

> Hi Peter,
>
> On Fri, Jan 1, 2021 at 10:46 AM Peter Toye  wrote:
>
>> Carl,
>>
>
>
>> [...]
>>
>
>
>> I hate to say it but I think the documentation is failing here, but can't
>> see how to mend it easily. To start with, maybe a list of all the publicly
>> available functions and their descriptions, but I suspect it would be far
>> too long and need constant updating, which is not something that the LP
>> documenters like for obvious reasons. Could it be mechanised?
>>
>> Best regards,
>>
>> Peter
>>
>
> Here's something which will give you a list of all public Scheme functions
> with whatever docstring is available in the source:
>
> https://www.mail-archive.com/lilypond-user@gnu.org/msg100337.html
>
> Hope this helps--
> David
>

Re: A comment about the documentation

[Peter Toye]

David,

Wow! Thank you!  It works in 2.20.0 as well.

It seems I'm only 5 years out of date.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Friday, January 1, 2021, 5:19:10 PM, David Nalesnik wrote:


Hi Peter,

On Fri, Jan 1, 2021 at 10:46 AM Peter Toye  wrote:

Carl,
 

[...]
 

I hate to say it but I think the documentation is failing here, but can't see 
how to mend it easily. To start with, maybe a list of all the publicly 
available functions and their descriptions, but I suspect it would be far too 
long and need constant updating, which is not something that the LP documenters 
like for obvious reasons. Could it be mechanised?

Best regards,

Peter

Here's something which will give you a list of all public Scheme functions with 
whatever docstring is available in the source:

https://www.mail-archive.com/lilypond-user@gnu.org/msg100337.html

Hope this helps--
David 

Re: A comment about the documentation

[Peter Toye]

Pierre,

Merci beaucoup.

This partly solves the problem - but only for that particular snippet  How many 
other snippets are there which rely on undocumented public functions? And how 
many undocumented functions are there which don't appear in any snippets?

The problem is that if some functionality in a programming system needs a 
search through thousands of lines of code to discover it, it won't be used. I 
thought that the LP ethos was to make its extreme flexibility available to the 
general user (OK, they need to know programming and list processing as well). 
But to hide functionality away, however unintentionally, seems to contradict 
this. I agree that there is a large body of people who are only too willing to 
help (three on this thread alone), and maybe the number of queries you all get 
does not add much to the workload, but personally I much prefer sitting down 
with a manual and working it out myself. As an ex-professional programmer I'm 
quite used to learning syntax, but the details of how to match function to 
functionality has always been a problem - one really needs a telepathic I/O 
device.

For LP objects this problem is touched upon in the Learning Manual, where ways 
of finding the correct section in the Internals Reference are discussed. 

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Friday, January 1, 2021, 5:01:27 PM, Pierre Perol-Schneider wrote:


I've added the github link in the snippet defs.
Cheers,
Pierre

Le ven. 1 janv. 2021 à 17:46, Peter Toye  a écrit :

Carl,

Thanks. The problem is that map-some-music is obviously a very useful function 
if you're trying to write code that performs an action at many places in a 
music expression, but there's no pointer to it. How the snippet writer found it 
I've obviously no idea (maybe they also wrote map-some-music). As it happens I 
wanted to do exactly what the snippet writer wanted so cutting and pasting were 
easy.

Another thing I want to do is to work out how to write a function that adds an 
octave beneath each note in a music expression to save a lot of time writing 
two-note chords.  I'm sure make-some-music will help here. But if I hadn't 
found the snippet, how would I ever have known where to look in the source - 
there's a lot of it?

I hate to say it but I think the documentation is failing here, but can't see 
how to mend it easily. To start with, maybe a list of all the publicly 
available functions and their descriptions, but I suspect it would be far too 
long and need constant updating, which is not something that the LP documenters 
like for obvious reasons. Could it be mechanised?

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Friday, January 1, 2021, 4:06:59 PM, Carl Sorensen wrote:





On Fri, Jan 1, 2021 at 8:59 AM Peter Toye  wrote:

Christian,

Thanks Christian. How one is meant to know this I have no idea. Maybe it was 
meant to be in the missing 3rd chapter of the Extending manual.

No, one is meant to search the source.  There are many scheme functions in the 
source that are used internally, but are not documented externally.  Advanced 
users will search the source code for these functions.  In the case of the LSR, 
you have examples of their use.  So you know the name of the function, and you 
can search the source to find the code.

If you are working on a machine (e.g. windows) that doesn't give you ready 
access to the source files, you can always go to the repository at GitLab or 
Savannah and search the source online.

Best wishes,

Carl

Re: A comment about the documentation

[David Nalesnik]

Hi Peter,

On Fri, Jan 1, 2021 at 10:46 AM Peter Toye  wrote:

> Carl,
>


> [...]
>


> I hate to say it but I think the documentation is failing here, but can't
> see how to mend it easily. To start with, maybe a list of all the publicly
> available functions and their descriptions, but I suspect it would be far
> too long and need constant updating, which is not something that the LP
> documenters like for obvious reasons. Could it be mechanised?
>
> Best regards,
>
> Peter
>

Here's something which will give you a list of all public Scheme functions
with whatever docstring is available in the source:

https://www.mail-archive.com/lilypond-user@gnu.org/msg100337.html

Hope this helps--
David

Re: A comment about the documentation

[Pierre Perol-Schneider]

I've added the github link in the snippet defs.
Cheers,
Pierre

Le ven. 1 janv. 2021 à 17:46, Peter Toye  a écrit :

> Carl,
>
> Thanks. The problem is that map-some-music is obviously a very useful
> function if you're trying to write code that performs an action at many
> places in a music expression, but there's no pointer to it. How the snippet
> writer found it I've obviously no idea (maybe they also wrote
> map-some-music). As it happens I wanted to do exactly what the snippet
> writer wanted so cutting and pasting were easy.
>
> Another thing I want to do is to work out how to write a function that
> adds an octave beneath each note in a music expression to save a lot of
> time writing two-note chords.  I'm sure make-some-music will help here. But
> if I hadn't found the snippet, how would I ever have known where to look in
> the source - there's a lot of it?
>
> I hate to say it but I think the documentation is failing here, but can't
> see how to mend it easily. To start with, maybe a list of all the publicly
> available functions and their descriptions, but I suspect it would be far
> too long and need constant updating, which is not something that the LP
> documenters like for obvious reasons. Could it be mechanised?
>
> Best regards,
>
> Peter
> mailto:lilyp...@ptoye.com 
> www.ptoye.com
> 
> -
> Friday, January 1, 2021, 4:06:59 PM, Carl Sorensen wrote:
>
>
>
>
>
> On Fri, Jan 1, 2021 at 8:59 AM Peter Toye  wrote:
>
> Christian,
>
> Thanks Christian. How one is meant to know this I have no idea. Maybe it
> was meant to be in the missing 3rd chapter of the Extending manual.
> No, one is meant to search the source.  There are many scheme functions in
> the source that are used internally, but are not documented externally.
> Advanced users will search the source code for these functions.  In the
> case of the LSR, you have examples of their use.  So you know the name of
> the function, and you can search the source to find the code.
>
> If you are working on a machine (e.g. windows) that doesn't give you ready
> access to the source files, you can always go to the repository at GitLab
> or Savannah and search the source online.
>
> Best wishes,
>
> Carl
>

Re: A comment about the documentation

[Peter Toye]

Carl,

Thanks. The problem is that map-some-music is obviously a very useful function 
if you're trying to write code that performs an action at many places in a 
music expression, but there's no pointer to it. How the snippet writer found it 
I've obviously no idea (maybe they also wrote map-some-music). As it happens I 
wanted to do exactly what the snippet writer wanted so cutting and pasting were 
easy.

Another thing I want to do is to work out how to write a function that adds an 
octave beneath each note in a music expression to save a lot of time writing 
two-note chords.  I'm sure make-some-music will help here. But if I hadn't 
found the snippet, how would I ever have known where to look in the source - 
there's a lot of it?

I hate to say it but I think the documentation is failing here, but can't see 
how to mend it easily. To start with, maybe a list of all the publicly 
available functions and their descriptions, but I suspect it would be far too 
long and need constant updating, which is not something that the LP documenters 
like for obvious reasons. Could it be mechanised?

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Friday, January 1, 2021, 4:06:59 PM, Carl Sorensen wrote:




On Fri, Jan 1, 2021 at 8:59 AM Peter Toye  wrote:

Christian,

Thanks Christian. How one is meant to know this I have no idea. Maybe it was 
meant to be in the missing 3rd chapter of the Extending manual.

No, one is meant to search the source.  There are many scheme functions in the 
source that are used internally, but are not documented externally.  Advanced 
users will search the source code for these functions.  In the case of the LSR, 
you have examples of their use.  So you know the name of the function, and you 
can search the source to find the code.

If you are working on a machine (e.g. windows) that doesn't give you ready 
access to the source files, you can always go to the repository at GitLab or 
Savannah and search the source online.

Best wishes,

Carl

Re: A comment about the documentation

[Carl Sorensen]

On Fri, Jan 1, 2021 at 8:59 AM Peter Toye  wrote:

> Christian,
>
> Thanks Christian. How one is meant to know this I have no idea. Maybe it
> was meant to be in the missing 3rd chapter of the Extending manual.
>

No, one is meant to search the source.  There are many scheme functions in
the source that are used internally, but are not documented externally.
Advanced users will search the source code for these functions.  In the
case of the LSR, you have examples of their use.  So you know the name of
the function, and you can search the source to find the code.

If you are working on a machine (e.g. windows) that doesn't give you ready
access to the source files, you can always go to the repository at GitLab
or Savannah and search the source online.

Best wishes,

Carl

Re: A comment about the documentation

[Peter Toye]

Christian,

Thanks Christian. How one is meant to know this I have no idea. Maybe it was 
meant to be in the missing 3rd chapter of the Extending manual.

Best regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

-
Friday, January 1, 2021, 12:38:33 PM, Christian Masser wrote:


Hi Peter!

It seems to be defined here: 
https://github.com/lilypond/lilypond/blob/master/scm/music-functions.scm#L2036 

All the best and a happy new year,

Christian

Am Fr., 1. Jan. 2021 um 13:29 Uhr schrieb Peter Toye :

It seems that I'm probably going to be doing more engraving after all.

I have a comment about the documentation. I wanted to add the same articulation 
to all notes in a music expression, and found 
http://lsr.di.unimi.it/LSR/Item?id=82 which does exactly what I want.

I noticed that it uses a function called 'map-some-music' and I can't find any 
reference to this in the Extending or Internals manuals. It seems to have the 
function of traversing a music expression and doing things to it - but is there 
a definition of its function anywhere? It would seem to be very useful.
 
A happy 2021 to all Ponders - may it bring vaccinations,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

Re: A comment about the documentation

[Christian Masser]

Hi Peter!

It seems to be defined here:
https://github.com/lilypond/lilypond/blob/master/scm/music-functions.scm#L2036


All the best and a happy new year,

Christian

Am Fr., 1. Jan. 2021 um 13:29 Uhr schrieb Peter Toye :

> It seems that I'm probably going to be doing more engraving after all.
>
> I have a comment about the documentation. I wanted to add the same
> articulation to all notes in a music expression, and found
> http://lsr.di.unimi.it/LSR/Item?id=82 which does exactly what I want.
>
> I noticed that it uses a function called 'map-some-music' and I can't find
> any reference to this in the Extending or Internals manuals. It seems to
> have the function of traversing a music expression and doing things to it -
> but is there a definition of its function anywhere? It would seem to be
> very useful.
>
> A happy 2021 to all Ponders - may it bring vaccinations,
>
> Peter
> mailto:lilyp...@ptoye.com 
> www.ptoye.com
>

A comment about the documentation

[Peter Toye]

It seems that I'm probably going to be doing more engraving after all. 

I have a comment about the documentation. I wanted to add the same articulation 
to all notes in a music expression, and found 
http://lsr.di.unimi.it/LSR/Item?id=82 which does exactly what I want.

I noticed that it uses a function called 'map-some-music' and I can't find any 
reference to this in the Extending or Internals manuals. It seems to have the 
function of traversing a music expression and doing things to it - but is there 
a definition of its function anywhere? It would seem to be very useful.
 
A happy 2021 to all Ponders - may it bring vaccinations,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

Call for help on Lyric Notation project

[Jean Abou Samra]

Hello,

Some time ago, Michael Blankenship asked for assistance on this list
(https://lists.gnu.org/archive/html/lilypond-user/2020-10/msg00497.html)
for custom phonetic notation of lyrics as music, something that he
is working on as part of his Ph.D.

I ended up writing some code (roughly a thousand lines) over here:

https://gitlab.com/jeanas/lyric-notation

While the project is advanced, it is not yet complete. I would
appreciate help from other coders to move this forward.

Here are five good reasons to take this offer:

- It is fun.

- You might learn a lot about LilyPond (as I did).

- It helps someone.

- It might bring LilyPond some reputation in academic circles.

- It would make an excellent example for the
http://lilypond.org/examples.html page.

If you are curious, go clone the repository and start exploring. In case
you are not familiar with Git, you may just download the sources as a
ZIP archive from
https://gitlab.com/jeanas/lyric-notation/-/archive/master/lyric-notation-master.zip
Or you may read the Git bootcamp and cheat sheet at
http://lilypond.org/doc/v2.21/Documentation/contributor/working-with-source-code 



On the project's front page at GitLab, and in the README.rst from the
source, you can read some documentation about how it works.

Issues to tackle are here:
https://gitlab.com/jeanas/lyric-notation/-/issues 



Feel free to ask any questions. Please reply to this message if you
are interested.

A happy new year to everyone!
Jean

Re: Spacing between clef and first note without time signature

[Xavier Scheuer]

On Fri, 1 Jan 2021 at 05:31, Jay Anderson  wrote:
>
> Not a great title, but here's what I'm wanting to achieve:
>
> =
> \version "2.20.0"
>
> \score {
>   \new Staff { c''2 r }
>   \layout {
> \context {
>   \Staff
>   \omit TimeSignature
> }
>   }
> }
> =
>
> This looks mostly correct until I reduce the staff size and squeeze it
horizontally:
>
> =
> \version "2.20.0"
>
> \score {
>   \new Staff { c''2 r }
>   \layout {
> line-width = 15\mm
> \context {
>   \Staff
>   \omit TimeSignature
> }
> #(layout-set-staff-size 14)
>   }
> }
> =
>
> The space between the clef and the first note is not compressible (almost
as if it's still leaving space for the time signature). Is there a way to
squeeze this? I'm wanting this in a footnote and it needs to be reduced in
size to look right. Thanks for the help.

Hi Jay,

The space between Clef and first-note is documented in the Internals
References manual,
IR 3.1.26 Clef
http://lilypond.org/doc/v2.20/Documentation/internals/clef

You can modify the space-alist property for the first-note item. Either by
changing the spacing-style to a stretchable (or semi-fixed) space or by
reducing the value of minimum-fixed-space.

Cheers,
Xavier

-- 
Xavier Scheuer