Re: Labels for ties and slurs

[Dan Eble]

On Oct 22, 2022, at 09:16, Jean Abou Samra  wrote:
> 
> We have many issues related to ties and to slurs. Would anybody mind creating 
> two GitLab labels ~"Ties" and ~"Slurs" for these? It would ease searching for 
> defects in those specific areas.

I don't have a problem with your creating any labels that you deem useful.
— 
Dan

Re: Labels for ties and slurs

[Jean Abou Samra]

Le 24/10/2022 à 13:18, Dan Eble a écrit :

On Oct 22, 2022, at 09:16, Jean Abou Samra  wrote:

We have many issues related to ties and to slurs. Would anybody mind creating two GitLab labels 
~"Ties" and ~"Slurs" for these? It would ease searching for defects in those 
specific areas.

I don't have a problem with your creating any labels that you deem useful.



Done.

https://gitlab.com/lilypond/lilypond/-/issues/?sort=created_date&state=opened&label_name%5B%5D=Ties&first_page_size=100
https://gitlab.com/lilypond/lilypond/-/issues/?sort=created_date&state=opened&label_name%5B%5D=Slurs&first_page_size=100

Cheers,
Jean

Re: New Lilypond logo?

[Jean Abou Samra]

Le 24/10/2022 à 12:11, Martín Rincón Botero a écrit :

Hi,

I've been toying with the amazing DALL·E seeing if it can produce a new
modern logo for e.g. the Lilypond website. Amongst all the amazing art it
produced, one in particular caught my attention as a potential logo. If
anyone in the future is interested in revamping the lilypond.org website,
perhaps this could be at the least an inspiration. I attached the full size
file. The incantation used to produce this was: "a white lily on two big
round leaves. Flat style".




I think that the discussion about restyling the website pops up
every n years, because different people have different opinions on
what is good or modern style.

If you want my subjective personal opinion: the current logo
and website are just fine.

Cheers,
Jean

Re: LilyPond 2.23.80

[Benjamin Tordoff]

Thanks to all the lilypond devs for their hard work. I installed the new 
version this morning and set it off rebuilding all of my scores. Some 136 
scores and 1500+ parts later it is done. Only 2 failed to build and both 
because I had defined my own markup "\fine" for faking DC al fine / DS al fine 
that conflicts with the new official way to do this. I will update those 
scores. There's far too much here to visually inspect every page but all of the 
scores and parts I've looked through so far look really good.

Great job!

Ben

PS: These are all modern classical notation but range in age from 20 year old 
scores that have been gradually updated as lilypond has evolved to brand new 
scores that use the new segno repeats and other modern tricks. You can see 
samples at pluralsax.com/p/repertoire if you want (although I have yet to 
upload the newly built versions).


> On 22 Oct 2022, at 21:32, Jonas Hahnfeld via LilyPond user discussion 
>  wrote:
> 
> We are happy to announce the release of LilyPond 2.23.80. This is the
> first release candidate towards the next stable version 2.24.0 expected
> in December. Please test your scores with this version and report back
> the experience as well as any problems you encounter. Please refer to
> the Installing section in the Learning Manual for instructions how to
> set up the provided binaries:
> https://lilypond.org/doc/v2.23/Documentation/learning/installing

Re: New Lilypond logo?

[Carl Sorensen]

On Mon, Oct 24, 2022 at 4:27 AM Martín Rincón Botero <
martinrinconbot...@gmail.com> wrote:

> Hi,
>
> I've been toying with the amazing DALL·E seeing if it can produce a new
> modern logo for e.g. the Lilypond website.


Personally, I prefer the existing logo.  But I'm almost as old as a
dinosaur.

Carl

Is a texi2any upgrade still wanted, and what would it take? (WAS: Re: New Lilypond logo?)

[Karlin High]

On 10/24/2022 10:12 AM, Jean Abou Samra wrote:

If you want my subjective personal opinion: the current logo
and website are just fine.


I understand there is a technical-debt issue in this area, though. 
Related to an old version of Texinfo, and the older texi2html vs the 
newer texi2any. Which is to generate the website concurrently with the 
rest of the documentation.


Near as I can tell, this reference best captures the issue:



I have had my eye on this area as a potential future personal project, a 
long-term seasons-of-code level effort.


However, my levels of Linux development know-how are quite varied. What 
foundational knowledge would be needed for that effort? Reading the 
texinfo 1.82 manual, as well as a newer version?

--
Karlin High
Missouri, USA

Re: Is a texi2any upgrade still wanted, and what would it take? (WAS: Re: New Lilypond logo?)

[Jean Abou Samra]

Le 24/10/2022 à 18:09, Karlin High a écrit :
I understand there is a technical-debt issue in this area, though. 
Related to an old version of Texinfo, and the older texi2html vs the 
newer texi2any. Which is to generate the website concurrently with the 
rest of the documentation.



Yes.



Near as I can tell, this reference best captures the issue:



I have had my eye on this area as a potential future personal project, 
a long-term seasons-of-code level effort.


However, my levels of Linux development know-how are quite varied. 
What foundational knowledge would be needed for that effort? Reading 
the texinfo 1.82 manual, as well as a newer version?




The work amounts to:

- Reading and understanding the contents of our
  Documentation/lilypond-texi2html.init texi2html configuration file
  (over a thousand lines of Perl code), and porting that to texi2any.

- Along the way, identifying what features are missing in texi2any,
  and asking upstream to implement them; the maintainer expressed
  willingness to do that just today:

https://lists.gnu.org/archive/html/help-texinfo/2022-10/msg6.html

- Amending the build system to search and invoke texi2any instead of 
texi2html
  (in configure.ac, Documentation/GNUmakefile, etc.), and building 
updated Docker

  images for the GitLab CI system.

- Possibly revamping (?) the way cross-references work
  (scripts/build/extract_texi_filenames, etc.) to cater for the new tool.

Don't be mistaken: this is a large undertaking.

Personally, my dream would be to switch to a different documentation
tool entirely, like Sphinx, which supports HTML, LaTeX and Texinfo
output, with extensive HTML customization possibilities, and would
not need so much build system fuss (lilypond-book etc.), and supports
internationalization via po files on top of that. But that is going to
be controversial and the amount of work is magnitudes larger :)

Best,
Jean

Re: New Lilypond logo?

[Jean Abou Samra]

Le 24/10/2022 à 17:07, Carl Sorensen a écrit :

Personally, I prefer the existing logo.  But I'm almost as old as a
dinosaur.




I'm 19 years old and have the same opinion, so rest assured
you're not being entirely driven by whatever age you have.

Cheers,
Jean

Re: Is a texi2any upgrade still wanted, and what would it take?

[David Kastrup]

Jean Abou Samra  writes:

> Personally, my dream would be to switch to a different documentation
> tool entirely, like Sphinx, which supports HTML, LaTeX and Texinfo
> output, with extensive HTML customization possibilities, and would
> not need so much build system fuss (lilypond-book etc.),

How do you imagine the LilyPond images to arrive in the documentation
without the "build system fuss"?  The bulk of the lilypond-book fuss is
about efficiently compiling ten thousands of small LilyPond fragments
without recompiling duplicates appearing in multiple translations.

> and supports internationalization via po files on top of that. But
> that is going to be controversial and the amount of work is magnitudes
> larger :)

The problem is that an advertised feature set is comparatively useless
for imagining the amount of work before arriving at a satisfactorily
smoothly operating and efficient solution.

It is not uncommon to have a proof of concept running within less than a
week, with a satisfactory efficient solution adding years of
development.

-- 
David Kastrup

Sphinx (was: Is a texi2any upgrade still wanted, and what would it take?)

[Jean Abou Samra]

Le 24/10/2022 à 20:00, David Kastrup a écrit :

Jean Abou Samra  writes:


Personally, my dream would be to switch to a different documentation
tool entirely, like Sphinx, which supports HTML, LaTeX and Texinfo
output, with extensive HTML customization possibilities, and would
not need so much build system fuss (lilypond-book etc.),

How do you imagine the LilyPond images to arrive in the documentation
without the "build system fuss"?  The bulk of the lilypond-book fuss is
about efficiently compiling ten thousands of small LilyPond fragments
without recompiling duplicates appearing in multiple translations.




Sphinx supports arbitrary roles and directives, which are similar to
Texinfo commands and environments. Texinfo has macros, but they can't
capture the literal input without Texinfo macro expansion (@verbatim is
special and you could not redefine it as a custom macro), and they don't
have a programming language available to them. In Sphinx, this is just
a matter of reading the LilyPond input in a Python extension and inserting
the output at that point, as is already done in

https://pypi.org/project/sphinxcontrib-lilypond/
or the alternative
https://github.com/sphinx-notes/lilypond

Which means that there is no longer a need to parse and pre-process
the source ourselves with regexes in lilypond-book, with the associated
build system fuss. Everything remains in the .rst or .md source files.
There is a built-in mechanism for serialisation of the build environment
and documentation data structures, using the Python pickle module,
so I think you can add the images to that in order to cache them and
worry less about how to store the cache on the disk. (But I'm not
an expert and I didn't study the extensions linked above that
extensively.)

Plus, dependency management across multiple files is built-in,
so you don't need to define the build process in Makefiles yourself.
(Extensions can hook into that.)




and supports internationalization via po files on top of that. But
that is going to be controversial and the amount of work is magnitudes
larger :)

The problem is that an advertised feature set is comparatively useless
for imagining the amount of work before arriving at a satisfactorily
smoothly operating and efficient solution.

It is not uncommon to have a proof of concept running within less than a
week, with a satisfactory efficient solution adding years of
development.




Yes, I am aware of that. If it were easy, I would have proposed doing this
long ago.

Re: Sphinx

[David Kastrup]

Jean Abou Samra  writes:

> Le 24/10/2022 à 20:00, David Kastrup a écrit :
>> Jean Abou Samra  writes:
>>
>>> Personally, my dream would be to switch to a different documentation
>>> tool entirely, like Sphinx, which supports HTML, LaTeX and Texinfo
>>> output, with extensive HTML customization possibilities, and would
>>> not need so much build system fuss (lilypond-book etc.),
>> How do you imagine the LilyPond images to arrive in the documentation
>> without the "build system fuss"?  The bulk of the lilypond-book fuss is
>> about efficiently compiling ten thousands of small LilyPond fragments
>> without recompiling duplicates appearing in multiple translations.
>
>
>
> Sphinx supports arbitrary roles and directives, which are similar to
> Texinfo commands and environments. Texinfo has macros, but they can't
> capture the literal input without Texinfo macro expansion (@verbatim is
> special and you could not redefine it as a custom macro), and they don't
> have a programming language available to them. In Sphinx, this is just
> a matter of reading the LilyPond input in a Python extension and inserting
> the output at that point, as is already done in
>
> https://pypi.org/project/sphinxcontrib-lilypond/
> or the alternative
> https://github.com/sphinx-notes/lilypond
>
> Which means that there is no longer a need to parse and pre-process
> the source ourselves with regexes in lilypond-book, with the associated
> build system fuss. Everything remains in the .rst or .md source files.
> There is a built-in mechanism for serialisation of the build environment
> and documentation data structures, using the Python pickle module,
> so I think you can add the images to that in order to cache them and
> worry less about how to store the cache on the disk. (But I'm not
> an expert and I didn't study the extensions linked above that
> extensively.)
>
> Plus, dependency management across multiple files is built-in,
> so you don't need to define the build process in Makefiles yourself.
> (Extensions can hook into that.)

I think you'd be seriously seriously surprised at the difference in
efficiency when _not_ deduplicating snippets and rolling hundreds of
them into a single LilyPond call.

The basics of lilypond-book where you can think of how to map them to
Spinx are not the ones responsible for doing the really heavy lifting.

-- 
David Kastrup

PATCHES - Countdown to October 26

[Colin Campbell]

Here is the current countdown report. 
The next countdown will begin on October 26th. 
A list of all merge requests can be found here: 
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority 


Push: 

!1678 Fix syntax-rules indentation - Jean Abou Samra 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1678 

!1676 Doc-NR: add missing [verbatim,quote] on some snippets in Text marks - 
Jean Abou Samra 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1676 

!1674 Snippet: changes to controlling-tuplet-bracket-visibility - Martφn Rinc≤n 
Botero 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1674 

!1646 Tuplet brackets: make bracket span all note heads - Martφn Rinc≤n Botero 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1646 


Countdown: 

!1686 web: Added Spontini-Editor to the easier-editing list - Paolo Prete 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1686 

!1683 doc: Ensure horizontal padding between HTML table elements - Werner 
Lemberg 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1683 

!1682 HTML formatting improvements of `@multitable` - Werner Lemberg 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1682 

!1680 [doc] Improve `lilypond-book`'s description of its texinfo support - 
Werner Lemberg 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1680 

!1679 Rests don't change slur direction - Martφn Rinc≤n Botero 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1679 

!1652 texinfo.tex: Update to upstream version - Werner Lemberg 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1652 


Review: 

!1688 Remove "const" from a bunch of Grob methods - Jean Abou Samra 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1688 

!1687 Rational cleaning - Dan Eble 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1687 

!1684 Don't print tuplet bracket when tuplet number is wider - Martφn Rinc≤n 
Botero 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1684 

!1677 max-slope-factor for tuplet brackets - Martφn Rinc≤n Botero 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1677 


New: 

!1689 convertrules.py: define path_replace on toplevel - Jean Abou Samra 
https://gitlab.com/lilypond/lilypond/-/merge_requests/1689 


Waiting: 

No patches in Waiting at this time. 

Cheers, 
Colin 

Re: PATCHES - Countdown to October 26

[Jean Abou Samra]

Le 25/10/2022 à 01:39, Colin Campbell a écrit :

Martφn Rinc≤n Botero



Let me make a guess: you wrote this from a Windows device. :)

Cheers,
Jean

lilypond-2.23.80

[Jonas Hahnfeld via Discussions on LilyPond development]

Hi,

Please find a new tarball for LilyPond at

http://lilypond.org/downloads/sources/v2.23/lilypond-2.23.80.tar.gz

Cheers,
Jonas


signature.asc
Description: This is a digitally signed message part