LilyPond 2.23.14, avec un appel à testeurs

Bonsoir à toutes et à tous,

En bon crieur public de service, j'ai le plaisir de vous annoncer la
parution de la version 2.23.14. C'est une version instable, la dernière
version stable étant la 2.22.2. Les binaires sont ici :

https://lilypond.org/development.fr.html

Les instructions d'installation ici :

https://lilypond.org/doc/v2.23/Documentation/learning/installing

La liste des changements ici en français :

https://lilypond.org/doc/v2.23/Documentation/changes/index.fr.html

et ici en anglais (la traduction française n'a pas encore
eu le temps d'intégrer les nouveautés très récentes) :

https://lilypond.org/doc/v2.23/Documentation/changes/index.html

Je rappelle qu'en passant à une nouvelle version, il faut
toujours passer convert-ly sur ses fichiers, pour faire toutes
les mises à jour de syntaxe nécessaires. Dans Frescobaldi,
c'est dans Outils > Mettre à jours avec convert-ly, et en ligne
de commande, il suffit d'utiliser la commande « convert-ly »,
sœur de la commande « lilypond ».

Voilà maintenant la partie la plus importante de ce message :
cette version a besoin de testeurs. En effet, si tout se
passe bien avec cette version, la suivante sera une version
bêta de la prochaine version stable, 2.24, ce qui signifie
notamment que la syntaxe et les fonctionnalités seront figées
afin de laisser aux gens (notamment aux codeurs Scheme) le
temps de se préparer. Seules les corrections de bug seront
intégrées à la version 2.24 à partir de ce moment-là, les nouvelles
fonctionnalités allant dans la 2.25 (instable). En particulier,
si des changements de syntaxe s'avéraient nécessaires pour régler
un bug, il est souhaitable que cela soit détecté le plus tôt
possible. Donc, si vous utilisez LilyPond sur des projets
importants, vous êtes fortement encouragé(e) à tester que
cette version fonctionne comme il se doit modulo les changements
qui sont voulus (qui sont décrits dans la liste des nouveautés
dont le lien est ci-dessus, et avec lesquels convert-ly
se débrouille souvent bien). Rappelons qu'il n'y a aucun problème
à avoir plusieurs versions en parallèle, vous pouvez tout à fait
installer celle-ci juste pour tester tout en restant en 2.22
pour vos projets.

Pour vous allécher, voici les quelques nouvelles fonctionnalités
les plus importantes dans cette version, ainsi que dans la 2.23.13
pour laquelle je n'avais pas fait d'annonce. Il y en a d'autres,
ainsi que des corrections de bugs comme d'habitude.

- Il y a une nouvelle option, « compile-scheme-code », qui utilise
un mécanisme différent pour exécuter le code Scheme. Cela donne
de meilleurs messages d'erreur, qui indiquent le numéro de ligne
précis où l'erreur s'est produite, et pas juste le numéro de ligne
de l'expression Scheme entière qui a conduit à l'erreur. Cela s'active
soit en passant -dcompile-scheme-code en ligne de commande, soit en
mettant au début du fichier .ly, avant tout code Scheme :

#(ly:set-option 'compile-scheme-code)

Par contre, il faut savoir qu'il y a quelques limitations, voir le tout
dernier point de
https://lilypond.org/doc/v2.23/Documentation/changes/index.html

- La commande \caesura n'est plus limitée au grégorien mais sert
désormais aussi aux césures modernes. Avec un simple \caesura,
on obtient le signe de césure. Avec des retouches simples, il
est possible d'obtenir d'autres genres de pauses. Par exemple,
il était jusqu'ici compliqué de mettre des points d'orgue sur
les barres de mesure (https://lsr.di.unimi.it/LSR/Item?id=10),
alors qu'avec \caesura c'est un jeu d'enfant :

{
c'1
\once \set Staff.caesuraType = #'()
\caesura ^\fermata _\fermata
}

Pour plus d'infos :

https://lilypond.org/doc/v2.23/Documentation/notation/writing-rests#caesuras

- Suite notamment à des discussions avec Vincent, deux commandes ont
fait leur apparition, \textMark et \textEndMark. Elles ajoutent des
indications textuelles entre les notes, un peu comme \mark "truc" ou
\mark \markup ..., sauf qu'elles sont plus adaptées pour le texte,
par opposition aux repères A, B, C, ... L'une des différences est que
\mark ne permet pas d'avoir plusieurs textes au même moment, sujet sur
lequel Vincent a écrit un article détaillé :
https://myrealbook.vintherine.org/double-marks.html
Maintenant, avec \textMark et \textEndMark, les snippets doubleMark
et polyMark ne sont plus nécessaires.

Il y a d'autres différences, notamment le grob créé, qui est un
TextMark au lieu d'un RehearsalMark.

Pour plus d'infos :

https://lilypond.org/doc/v2.23/Documentation/notation/writing-text.html#text-marks

(en anglais pour 2.23.14, mais la version française arrive déjà grâce
à Jean-Charles Malahieude qui traduit plus vite que son ombre).

C'est tout, et c'est déjà bien assez. Bonnes LilyPonderies, et à
bientôt sur la liste,

Jean

Bonjours à toutes et à tous Je me suis donc installé un environnement de test et j'ai compilé sans autre changement qu'un convert-ly. Première erreur dans l'ordre des contenus pdf de la table des matières : le tocAct apparaît le premier tocItem et non pas avant comme il se devrait. Bonne semaine

···

Le 10/10/2022 à 00:13, Jean Abou Samra a écrit :

cette version a besoin de testeurs.

après

-- 
Vincent Gay
Envoyé depuis mon saxo-phone :)
[https://myrealbook.vintherine.org/](https://myrealbook.vintherine.org/) - [http://photos.vintherine.org/](http://photos.vintherine.org/)

J'ai testé ça dans tous les sens, empilés les eux sur les autres, avec des \tweak, avec des \override... Nickel. Maintenant je n'ai réellement plus besoins de polyMark (J'ai juste 120 fichiers à rectifier pour mon recueil :angry:) Juste une petite remarque à propos de la taille de la police par défaut : elle est équivalente à un simple \markup, inférieure à celle obtenue par un \mark \markup. Cela se règle aisément par un \override Score.TextMark.font-size = #2

···

Le 10/10/2022 à 00:13, Jean Abou Samra a écrit :

deux commandes ont fait leur apparition, \textMark et \textEndMark.

-- 
Vincent Gay
Envoyé depuis mon saxo-phone :)
[https://myrealbook.vintherine.org/](https://myrealbook.vintherine.org/) - [http://photos.vintherine.org/](http://photos.vintherine.org/)

Bonjour,
petite amélioration qui n'est pas indispensable, vu que Lily renvoie un bip d'erreur !
Lily criait déjà pour la version 13, le convert-ly ne convertit pas (#') en point (.)

exemple

\override VerticalAxisGroup #'remove-first = ##t

n'est pas converti en

\override VerticalAxisGroup.remove-first = ##t

Bonne journée et merci pour cette version 2.23.14

···

Martial Rameaux

Je parie que tu as encore le code que je t’avais donné ici : https://lists.gnu.org/archive/html/lilypond-user-fr/2022-08/msg00078.html

C’est un contournement du bug qui inverse les items du contenu qui pointent vers un même page. Le contournement consiste à les réinverser. Or le bug a été réglé en 2.23.13, donc il suffit d’enlever le contournement qui réinverse et tout devrait rentrer dans l’ordre.

···

Le 10 oct. 2022 à 11:36, Vincent Gay <****@****> a écrit :

Je me suis donc installé un environnement de test et j'ai compilé sans autre changement qu'un convert-ly. Première erreur dans l'ordre des contenus pdf de la table des matières : le tocAct apparaît après le premier tocItem et non pas avant comme il se devrait.

deux commandes ont fait leur apparition, \textMark et \textEndMark.

J'ai testé ça dans tous les sens, empilés les eux sur les autres, avec des \tweak, avec des \override... Nickel. Maintenant je n'ai réellement plus besoins de polyMark

Super.

(J'ai juste 120 fichiers à rectifier pour mon recueil :angry:)

Ce qui favoriserait la cohérence mais n’est pas indispensable non plus, à ta place je ne suis pas sûr que je m’embêterais. Cela dit, en fonction de la manière dont tu as écrit ton code existant, peut-être que tu pourrais convertir une majorité des cas avec un script sed ou autre, et ainsi rendre la tâche moins grosse ?

Juste une petite remarque à propos de la taille de la police par défaut : elle est équivalente à un simple \markup, inférieure à celle obtenue par un \mark \markup. Cela se règle aisément par un \override Score.TextMark.font-size = #2

C’est voulu. Je trouvais que les RehearsalMark étaient trop grosses dans les cas comme « ad lib ». TextMark a une taille par défaut qui est quand même légèrement plus grosse que TextScript, mais effectivement nettement plus petite que RehearsalMark.

De toute façon, étant donné que ces nouvelles commandes peuvent servir à beaucoup de choses différentes, j’ai bien peur qu’il n’y ait pas de « bonne » valeur par défaut universelle.

···

Le 10 oct. 2022 à 11:59, Vincent Gay <****@****> a écrit :
Le 10/10/2022 à 00:13, Jean Abou Samra a écrit :

Bonjour,

Oui, ça a déjà été signalé sur la liste anglophone mais ça m’était sorti de la tête, merci de me le rappeler. L’affaire, c’est que la nouvelle syntaxe a été introduite il y a longtemps, dans la version 2.17.6, avec prise en charge dans convert-ly, tandis que la version 2.23.13 n’a ajouté qu’un avertissement sur l’ancienne syntaxe. On peut donc forcer convert-ly à faire cette conversion en faisant une mise à jour de 2.17.5 vers 2.17.6 :

convert-ly --from 2.17.5 --to 2.17.6 fichier.ly

Cordialement,
Jean

···

Le 10 oct. 2022 à 12:01, Martial R <****@****> a écrit :

Bonjour,
petite amélioration qui n'est pas indispensable, vu que Lily renvoie un bip d'erreur !
Lily criait déjà pour la version 13, le convert-ly ne convertit pas (#') en point (.)
exemple
  \override VerticalAxisGroup #'remove-first = ##t
n'est pas converti en
  \override VerticalAxisGroup.remove-first = ##t

Bonne journée et merci pour cette version 2.23.14

Arf... C'est encore plus bête que ça ! Pourquoi je ne sais pas mais je l'avais mis à 2 endroits : le fichier principal et un fichiers inclus. J'avais pensé à l'enlever mais il en restait un bien caché.

Du coup c'est tout bon, merci.

···

Le 10/10/2022 à 12:47, Jean Abou Samra a écrit :

Je parie que tu as encore le code que je t’avais donné ici : Re: Signets de pages pdf

--
Vincent Gay
Envoyé depuis mon saxo-phone :slight_smile:
https://myrealbook.vintherine.org/ - http://photos.vintherine.org/

Ben si, mon recueil devrait être prêt pour la fin de l'année, donc pouvoir être en 2.24. J'aimerai qu'il soit aussi "propre" que possible puisque les sources sont incluses. Immodestement ça me ferait plaisir qu'il constitue une bonne illustration de ce que l'on peut faire avec Lilypond dans le monde du Jazz. Si je m'était comporté intelligemment partout de la même manière sans doute. Mais comme il s'agit de reprise de code datant, pour les plus vieux, de la 2.18 je retrouve plusieurs manière de traiter le même problème.

···

Le 10/10/2022 à 12:53, Jean Abou Samra a écrit :

J'ai juste 120 fichiers à rectifier pour mon recueil 😠)

Ce qui favoriserait la cohérence mais n’est pas indispensable non plus, à ta place je ne suis pas sûr que je m’embêterais. 
Cela dit, en fonction de la manière dont tu as écrit ton code existant, peut-être que tu pourrais convertir une majorité des cas avec un script sed ou autre, et ainsi rendre la tâche moins grosse ?
-- 
Vincent Gay
Envoyé depuis mon saxo-phone :)
[https://myrealbook.vintherine.org/](https://myrealbook.vintherine.org/) - [http://photos.vintherine.org/](http://photos.vintherine.org/)

Merci,
impeccable dans Frescobaldi

Outils

mettre à jour avec convert-ly

Depuis la version 2.17.5

Vers la version 2.17.6

Mis à jour avec le "." et passage direct en version 2.23.14

Cordialement

···

Martial Rameaux

Une petite observation :

···

Le 10/10/2022 à 11:58, Vincent Gay a écrit :

deux commandes ont fait leur apparition, \textMark et \textEndMark.

  • \textMark \markup 4x ça passe
  • \textMark "4x" ça passe
  • \textMark 4x ça coince

/home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/AGoGo.ly:54:16: Erreur : type d'argument erroné pour 1.

Attendait markup, 4 trouvé.

\textEndMark

4X

/home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/AGoGo.ly:54:17: Erreur : « X » n'est pas un nom de note

\textEndMark 4

X

erreur fatale : erreur sur les fichiers "/home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.ly"

Arrêté avec le code de retour 1.

-- 
Vincent Gay
Envoyé depuis mon saxo-phone :)
[https://myrealbook.vintherine.org/](https://myrealbook.vintherine.org/) - [http://photos.vintherine.org/](http://photos.vintherine.org/)

En fait oui, sed et grep me font gagner beaucoup de temps

···

Le 10/10/2022 à 12:53, Jean Abou Samra a écrit :

Cela dit, en fonction de la manière dont tu as écrit ton code existant, peut-être que tu pourrais convertir une majorité des cas avec un script sed ou autre, et ainsi rendre la tâche moins grosse ?

--
Vincent Gay
Envoyé depuis mon saxo-phone :slight_smile:
https://myrealbook.vintherine.org/ - http://photos.vintherine.org/

Au passage, `ripgrep` (aka `rg`) te ferait gagner plus de temps que `grep` :

  ┌────
  │ $ find /home/bitouze/texlive/2022/texmf-dist/tex/latex/ -type f | wc -l
  │ 18902
  │ $ time grep -r 'french' /home/bitouze/texlive/2022/texmf-dist/tex/latex/
  │ [...]
  │ 0,22s user 0,34s system 16% cpu 3,319 total
  │ $ time rg 'french' /home/bitouze/texlive/2022/texmf-dist/tex/latex/
  │ [...]
  │ 0,13s user 0,17s system 151% cpu 0,196 total
  └────

···

Le 10/10/22 à 18h01, Vincent Gay a écrit :

Le 10/10/2022 à 12:53, Jean Abou Samra a écrit :

Cela dit, en fonction de la manière dont tu as écrit ton code existant,

peut-être que tu pourrais convertir une majorité des cas avec un script sed ou
autre, et ainsi rendre la tâche moins grosse ?
En fait oui, sed et grep me font gagner beaucoup de temps

--
Denis

Ça, ça ne m'étonne pas, étant donné que tu peux écrire des choses comme

\scaleDurations 4 c

De là, il n'y a qu'un pas vers

\scaleDurations 4c

qui est aussi valide, car LilyPond n'est généralement pas sensible aux
espaces, et enfin

\scaleDurations 4x

où le « x » pourrait très bien être un nom de note dans un certain
\language.

On peut toujours imaginer accepter plus de choses dans la syntaxe, mais
il faut bien tracer une limite à un moment donné. Actuellement, la limite
est fixée sur le principe que les nombres et les caractères alphabétiques
sont dans des entités séparées, sauf à les mettre entre guillemets (ou dans
le mode \markup qui est quelque chose de complètement à part).

Cordialement,
Jean

···

Le 10/10/2022 à 15:31, Vincent Gay a écrit :

Le 10/10/2022 à 11:58, Vincent Gay a écrit :

deux commandes ont fait leur apparition, \textMark et \textEndMark.

Une petite observation :

  * \textMark \markup 4x ça passe
  * \textMark "4x" ça passe
  * \textMark 4x ça coince

/home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/AGoGo.ly:54:16: Erreur : type d'argument erroné pour 1.

Attendait markup, 4 trouvé.

\textEndMark

4X

/home/vincent/Nextcloud2/Musique/Recueils/Recueil-1/AGoGo.ly:54:17: Erreur : « X » n'est pas un nom de note

\textEndMark 4

X

erreur fatale : erreur sur les fichiers "/home/vincent/Nextcloud2/Musique/Recueils/Recueil-1.ly"

Arrêté avec le code de retour 1.

Hello Denis, je vais regarder ça Ce qui pourrait aussi me faire gagner beaucoup de temps serait de savoir utiliser sed avec des expressions contenant des \ principalement quelque chose comme ça Je ne sais pas comment échapper l'antislash. De plus comme tu le vois il y a aussi un quote dans l'expression à remplacer. Si quelqu'un a une solution je l'en remercie d'avance

···

Le 10/10/2022 à 18:36, Denis Bitouzé a écrit :

Au passage, `ripgrep` (aka `rg`) te ferait gagner plus de temps que `grep` :

sed -i "s/\polyMark #'rde/\tweak direction #DOWN \textEndMark/g" *.ly

-- 
Vincent Gay
Envoyé depuis mon saxo-phone :)
[https://myrealbook.vintherine.org/](https://myrealbook.vintherine.org/) - [http://photos.vintherine.org/](http://photos.vintherine.org/)

C'est une chose que j'ai mis un certain temps à comprendre.
Il faut mettre quatre antislashs d'affilée, car l'antislash
que tu recherches doit être échappé dans l'expression régulière,
donc en mettant deux antislashs, et chaque antislash
dans l'expression régulière doit être doublé pour Bash, ce
qui fait quatre au total. Par contre, en utilisant
des apostrophes ' au lieu des guillemets pour délimiter
la chaîne dans le script Bash, il n'y a plus besoin que
de deux antislashs.

Et pour le ' lui-même, dans une chaîne avec des " , pas
besoin de l'échapper, et sinon, avec des ' comme délimiteurs,
la syntaxe est assez bizarre :

sed 's/\\polyMark #'\''rde/\\tweak direction #DOWN \\textEndMark/g' *.ly

Au fait, avant de faire ça, j'espère que tu as une sauvegarde.
sed est magique, mais on a vite fait de se planter. (Je parle
d'expérience.)

Cordialement,
Jean

···

Le 10/10/2022 à 19:06, Vincent Gay a écrit :

Le 10/10/2022 à 18:36, Denis Bitouzé a écrit :

Au passage, `ripgrep` (aka `rg`) te ferait gagner plus de temps que `grep` :

Hello Denis, je vais regarder ça

Ce qui pourrait aussi me faire gagner beaucoup de temps serait de savoir utiliser sed avec des expressions contenant des \

principalement quelque chose comme ça

sed -i "s/\polyMark #'rde/\tweak direction #DOWN \textEndMark/g" *.ly

Je ne sais pas comment échapper l'antislash. De plus comme tu le vois il y a aussi un quote dans l'expression à remplacer.

Si quelqu'un a une solution je l'en remercie d'avance

pffff... C'est magique. Ça m'a fait gagner 3 ou4 heures de boulot. Après je devrai vérifier le résultat page par page mais de toutes manières j'aurai du le faire. A ce jour le recueil fait 306 pages, à l'arrivée il en fera 400 ou plus. Vive sed, vive grep, et merci Jean.

···

Le 10/10/2022 à 19:19, Jean Abou Samra a écrit :

sed 's/\\polyMark #'\''rde/\\tweak direction #DOWN \\textEndMark/g' *.ly

--
Vincent Gay
Envoyé depuis mon saxo-phone :slight_smile:
https://myrealbook.vintherine.org/ - http://photos.vintherine.org/

Merci pour le partage, Denis, je ne connaissais pas ripgrep, qui m'a l'air très pratique, notamment le fait qu'il exclue par défaut les fichiers binaires.

Cordialement,
Jean

···

Le 10/10/2022 à 18:36, Denis Bitouzé a écrit :

Le 10/10/22 à 18h01, Vincent Gay a écrit :

Le 10/10/2022 à 12:53, Jean Abou Samra a écrit :

Cela dit, en fonction de la manière dont tu as écrit ton code existant,

peut-être que tu pourrais convertir une majorité des cas avec un script sed ou
autre, et ainsi rendre la tâche moins grosse ?
En fait oui, sed et grep me font gagner beaucoup de temps

Au passage, `ripgrep` (aka `rg`) te ferait gagner plus de temps que `grep` :

   ┌────
   │ $ find /home/bitouze/texlive/2022/texmf-dist/tex/latex/ -type f | wc -l
   │ 18902
   │ $ time grep -r 'french' /home/bitouze/texlive/2022/texmf-dist/tex/latex/
   │ [...]
   │ 0,22s user 0,34s system 16% cpu 3,319 total
   │ $ time rg 'french' /home/bitouze/texlive/2022/texmf-dist/tex/latex/
   │ [...]
   │ 0,13s user 0,17s system 151% cpu 0,196 total
   └────

Merci pour le partage, Denis,

Je t'en prie.

je ne connaissais pas ripgrep, qui m'a l'air très pratique, notamment
le fait qu'il exclue par défaut les fichiers binaires.

N'exclue-t-il pas plutôt les fichiers listés dans ton `.gitignore` (et
donc les fichiers binaires) ?

Cordialement.

···

Le 10/10/22 à 23h08, Jean Abou Samra a écrit :
--
Denis