application métronome + drone

Bonjour à tous,

je me souviens avoir lu dans le forum que quelqu'un utilise une appli qui cumule les fonctions de métronome et de drone (équivalent d'un bourdon).

Je suis bien conscient du hors sujet vis à vis du thème du forum, mais... les applis que j'ai trouvées ne me satisfont pas et me voilà sans beaucoup de ressource.

Quelqu'un a t-il trouvé le Graal en la matière ?

d'avance, merci !

Nicolas

Sur Android, j’utilise personnellement “Practice Hub”, un programme
Libre qui fait métronome, bourdon et accordeur :

V.

···

On 11/22/21, nicolas Lehembre <****@****> wrote:

je me souviens avoir lu dans le forum que quelqu'un utilise une appli
qui cumule les fonctions de métronome et de drone (équivalent d'un
bourdon).

Bonsoir tout le monde,

J'ai installé LilyPond v 2.22.1 sous Windows 7 et après quelques essais je me suis aperçu que le caractère "à" dans les textes n'était pas représenté dans le PDF.

Le compilateur me revoie l'erreur "(lilypond-windows.exe:992): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()
Avertissement : aucun glyphe ne correspond au caractère U+FFFD dans la fonte « C:/Program Files (x86)/LilyPond/usr/share/lilypond/current/fonts/otf/C059-Roman.otf »

le caractère "à" est codé en UTF8 C3 A0 et pas FF FD.
Aucun soucis, semble-t-l avec les autres caractères spéciaux français. Je n'avais pas ce problème avec la version 2.20.0. Une idée ?

Cordialement
Jean-Paul Quelen

Excellent ! C'est exactement ce que je cherchais...pas pensé à F-Droid...
Merci Valentin !

···

Le 22 novembre 2021 17:29:45 Valentin Villenave <****@****> a écrit :

On 11/22/21, nicolas Lehembre <****@****> wrote:

je me souviens avoir lu dans le forum que quelqu'un utilise une appli
qui cumule les fonctions de métronome et de drone (équivalent d'un
bourdon).

Sur Android, j’utilise personnellement “Practice Hub”, un programme
Libre qui fait métronome, bourdon et accordeur :
Practice Hub | F-Droid - Free and Open Source Android App Repository

V.

J'ai trouvé une astuce : copier le "à" de C059-Roman.otf à l'emplacement FF FD à l'aide de FontForge ; ça marche mais avec l'erreur (lilypond-windows.exe:6808): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() et de toute façon ça fait bricolage.

Cordialement

Après plusieurs essais, il semble que le problème existe depuis la version 2.21.1-1.

···

Le 22/11/2021 à 19:40, Jean-Paul Quelen a écrit :

J'ai trouvé une astuce : copier le "à" de C059-Roman.otf à l'emplacement FF FD à l'aide de FontForge ; ça marche mais avec l'erreur (lilypond-windows.exe:6808): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() et de toute façon ça fait bricolage.

Cordialement

Bonjour,

Je n'ai pas l'explication du bug ni de solution, mais je voudrais
préciser les choses à propos d'Unicode et UTF-8.

J'ai installé LilyPond v 2.22.1 sous Windows 7 et après quelques essais
je me suis aperçu que le caractère "à" dans les textes n'était pas
représenté dans le PDF.

Le compilateur me revoie l'erreur "(lilypond-windows.exe:992):
Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()
Avertissement : aucun glyphe ne correspond au caractère U+FFFD dans la
fonte « C:/Program Files
(x86)/LilyPond/usr/share/lilypond/current/fonts/otf/C059-Roman.otf »

Le caractère U+FFFD est le « caractère de remplacement » Unicode : �.
C'est ce qu'utilisent habituellement les logiciels quand ils doivent
représenter en Unicode quelque chose qu'ils n'ont pas su reconnaître
comme un caractère.

le caractère "à" est codé en UTF8 C3 A0 et pas FF FD.

Attention, ici il y a une omission et une confusion. :wink:

La confusion, c'est que le caractère Unicode U+FFFD se code non pas
FF FD en UTF-8, mais EF BF BD.

L'omission, c'est que le caractère « à », a deux représentations en
Unicode, et donc en UTF-8 :
1) à = U+00E9 (Unicode) = C3 A0 (UTF-8)
2) à = U+0061 U+0300 (Unicode) = 61 CC 80 (UTF-8)

Aucun soucis, semble-t-l avec les autres caractères spéciaux français.
Je n'avais pas ce problème avec la version 2.20.0. Une idée ?

Est-ce que tu peux essayer de copier-coller depuis mon message dans
LilyPond les deux représentations de ce caractère, pour voir si l'une
fonctionne mieux que l'autre ?

Texte à copier-coller : "àà"

···

Le 22/11/2021 18:46, Jean-Paul Quelen a écrit :

Le 2° à (code 61 CC 80) fonctionne même si l'accent dans sa représentation dans le programme Frescobaldi est décalé (a `). Par contre pas de problème dans NotePad++.

Dans Frescobaldi je remplacerai tous les à (C3 A0) en à (61 CC 80). Ce n'est pas trop difficile à faire.
C'est quand même un bug depuis la version 2.21.1-1 et je ne connaissais pas le 2° code de ce caractère.
Merci pour votre aide.
Cordialement

Jean-Paul

Le [2e] à (code 61 CC 80) fonctionne même si l'accent dans sa
représentation dans le programme Frescobaldi est décalé (a `).

Je n'ai pas l'impression d'avoir le problème dans Frescobaldi
(version 3.0.0 sur Linux), mais j'ai juste utilisé l'éditeur
sans essayer de compiler une partition.

Par contre pas de problème dans NotePad++.

C'est déjà une bonne chose.

Dans Frescobaldi je remplacerai tous les à (C3 A0) en à (61 CC 80). Ce
n'est pas trop difficile à faire.

Noter que c'est quand même un moyen un peu lourd pour contourner un vrai
bug, qu'il serait bon d'identifier et corriger dans LilyPond.

C'est quand même un bug depuis la version 2.21.1-1 et je ne connaissais
pas le [2e] code de ce caractère.

La première forme (U+00A9) est dite forme précomposée, dans laquelle
un seul code Unicode représente le a avec son accent. Dans la forme
décomposée, il y a d'abord un a non accentué (U+0061) suivi d'un
code pour l'accent grave (U+0300).

Je n'ai encore jamais vu de logiciel sur Linux ou sur Windows utilisant
autre chose que la forme précomposée quand elle existe. En revanche j'en
ai déjà rencontré sur MacOS (je crois que c'était MacOS 9, pas MacOS X,
mais je n'en suis pas sûr).

Cordialement,

···

Le 23/11/2021 14:46, Jean-Paul Quelen a écrit :
--
Olivier Miakinen

Bonjour,

Je suis avec attention ce fil de discussion car j'ai eu le même problème

Je tape les partitions avec frescobaldi sous linux (debian)
Et mon compositeur les vérifie avec frescobaldi sous windows

Pour une partition, il m'a fait remonter un "gros bug" de à-accent
J'ai eu du mal à comprendre parce que, de mon côté, l'accent s'affichait parfaitement.

Il a fallu qu'on s'échange des captures d'écrans pour que je comprenne que le même fichier affichait des accents sous linux et un caractère vide sous windows

En bon linuxien, j'en ai conclu que c'était de la faute de windows ^^'

J'ai finalement publié le fichier tel quel, parce que je pensais qu'il y avait beaucoup plus d'utilisateurs de lilypond sous linux que sous windows, et que donc soit ça passerait inaperçu, soit ça serait corrigé un jour ou l'autre....

Donc s'il y a une solution, je suis preneur

Je n'ai pas bien compris concrètement comment je peux changer les à (C3 A0) en à (61 CC 80), si quelqu'un veut bien m'expliquer ?
Mais c'est une solution provisoire à ce que j'ai compris ?

Bonne journée à tous,
David

···

De : Olivier Miakinen <****@****>
À : lilypond-user-fr@gnu.org
Sujet : Re: Problème avec le à (a accent grave)
Date : 24/11/2021 00:41:40 Europe/Paris

Le 23/11/2021 14:46, Jean-Paul Quelen a écrit :

Le [2e] à (code 61 CC 80) fonctionne même si l'accent dans sa
représentation dans le programme Frescobaldi est décalé (a `).

Je n'ai pas l'impression d'avoir le problème dans Frescobaldi
(version 3.0.0 sur Linux), mais j'ai juste utilisé l'éditeur
sans essayer de compiler une partition.

Par contre pas de problème dans NotePad++.

C'est déjà une bonne chose.

Dans Frescobaldi je remplacerai tous les à (C3 A0) en à (61 CC 80). Ce
n'est pas trop difficile à faire.

Noter que c'est quand même un moyen un peu lourd pour contourner un vrai
bug, qu'il serait bon d'identifier et corriger dans LilyPond.

C'est quand même un bug depuis la version 2.21.1-1 et je ne connaissais
pas le [2e] code de ce caractère.

La première forme (U+00A9) est dite forme précomposée, dans laquelle
un seul code Unicode représente le a avec son accent. Dans la forme
décomposée, il y a d'abord un a non accentué (U+0061) suivi d'un
code pour l'accent grave (U+0300).

Je n'ai encore jamais vu de logiciel sur Linux ou sur Windows utilisant
autre chose que la forme précomposée quand elle existe. En revanche j'en
ai déjà rencontré sur MacOS (je crois que c'était MacOS 9, pas MacOS X,
mais je n'en suis pas sûr).

Cordialement,

Olivier Miakinen

Bonjour David,

···

Le 24/11/2021 07:23, ****@**** a écrit :

Je n'ai pas bien compris concrètement comment je peux changer les à
(C3 A0) en à (61 CC 80), si quelqu'un veut bien m'expliquer ?

Pour moi la méthode la plus simple passe par la page web suivante :
<http://hapax.qc.ca/conversion.fr.html&gt;\. On saisit quelque chose dans
une des boîtes, puis on clique ailleurs pour que les autres boîtes
se remplissent.

Il suffit alors de faire du copier-coller de caractères vers ou
depuis la boîte « Caractères ».

===

Par exemple si on saisit un e dans la boîte « Caractères », on voit
dans les autres boîtes que son code Unicode est 65 et son encodage
UTF-8 est aussi 65. Avec un é, on voit que son numéro Unicode (en
forme composée) est E9 et son encodage UTF-8 est C3 A9.

Pour avoir la forme décomposée de é, il faut mettre dans la boîte
de gauche le code du e (on vient de voir que c'est 65), et le
faire suivre par le code de l'accent aigu. Si on ne le connaît
pas par cœur, on peut essayer dans l'ordre tous les numéros
à partir de 300.

Boîte de gauche :
65 300 65 301 65 302 65 303 65 304 65 305 65 306 65 307
65 308 65 309 65 30A 65 30B 65 30C 65 30D 65 30E 65 30F

Résultat dans la boîte de droite :
èéêẽēe̅ĕėëẻe̊e̋ěe̍e̎ȅ

Du coup, le à en forme décomposée peut s'obtenir en saisissant 61
(le code du a) suivi de 300 (l'accent grave) dans la boîte en haut
à gauche. Note que si tu connais le codage UTF-8 plutôt que les
numéros de caractères tu peux aussi bien saisir « 61 CC 80 » dans
la boîte UTF-8, ça marche de la même manière.

Il suffit alors de faire un copier-coller avec la souris du caractère
« à » qui s'est affiché à droite.

===

Il y a beaucoup d'autres pépites sur cette page, par exemple des liens
vers les tableaux Unicode, et ce en français !

Mais c'est une solution provisoire à ce que j'ai compris ?

La solution est censée être pérenne. Je trouve juste que c'est un peu
compliqué de devoir copier-coller tous ses « à » au lieu de les saisir
directement au clavier. :wink:

Cordialement,
Olivier Miakinen

P.-S. : pour ceux que les jeux de caractères (hors Unicode) intéressent,
j'avais aussi commis la page suivante il y a quelques années :
<http://www.miakinen.net/vrac/charsets/&gt;

Bonjour,

L'astuce que j'ai trouvée consiste à taper dans NotePad++ muni du module d'extension HEX-Editor directement les codes hexadécimaux 61 CC 80. Puis je fais un "copier" du caractère puis un remplacement de "à" par ce caractère sous Frescobaldi ; ça marche mais cela fait un peu bricolage. Je vais regarder les répertoires LilyPond correspondant aux versions 2.21.1-1 et 2.21.2-1 car c'est entre ces 2 versions qu'est apparu le bug. Il est possible que ce soit dû à une dll ou un module qui ne fait par partie de LilyPond...

Ci-joint un exemple de fichier qui pose problème

À suivre
Jean-Paul Quelen

z.ly (52 Bytes)

···

Le 24/11/2021 à 07:23, ****@**** a écrit :

Bonjour,

Je suis avec attention ce fil de discussion car j'ai eu le même problème

Je tape les partitions avec frescobaldi sous linux (debian)
Et mon compositeur les vérifie avec frescobaldi sous windows

Pour une partition, il m'a fait remonter un "gros bug" de à-accent
J'ai eu du mal à comprendre parce que, de mon côté, l'accent s'affichait parfaitement.

Il a fallu qu'on s'échange des captures d'écrans pour que je comprenne que le même fichier affichait des accents sous linux et un caractère vide sous windows

En bon linuxien, j'en ai conclu que c'était de la faute de windows ^^'

J'ai finalement publié le fichier tel quel, parce que je pensais qu'il y avait beaucoup plus d'utilisateurs de lilypond sous linux que sous windows, et que donc soit ça passerait inaperçu, soit ça serait corrigé un jour ou l'autre....

Donc s'il y a une solution, je suis preneur

Je n'ai pas bien compris concrètement comment je peux changer les à (C3 A0) en à (61 CC 80), si quelqu'un veut bien m'expliquer ?
Mais c'est une solution provisoire à ce que j'ai compris ?

Bonne journée à tous,
David

De : Olivier Miakinen <****@****>
À : lilypond-user-fr@gnu.org
Sujet : Re: Problème avec le à (a accent grave)
Date : 24/11/2021 00:41:40 Europe/Paris

Le 23/11/2021 14:46, Jean-Paul Quelen a écrit :
> Le [2e] à (code 61 CC 80) fonctionne même si l'accent dans sa
> représentation dans le programme Frescobaldi est décalé (a `).

Je n'ai pas l'impression d'avoir le problème dans Frescobaldi
(version 3.0.0 sur Linux), mais j'ai juste utilisé l'éditeur
sans essayer de compiler une partition.

> Par contre pas de problème dans NotePad++.

C'est déjà une bonne chose.

> Dans Frescobaldi je remplacerai tous les à (C3 A0) en à (61 CC 80). Ce
> n'est pas trop difficile à faire.

Noter que c'est quand même un moyen un peu lourd pour contourner un vrai
bug, qu'il serait bon d'identifier et corriger dans LilyPond.

> C'est quand même un bug depuis la version 2.21.1-1 et je ne connaissais
> pas le [2e] code de ce caractère.

La première forme (U+00A9) est dite forme précomposée, dans laquelle
un seul code Unicode représente le a avec son accent. Dans la forme
décomposée, il y a d'abord un a non accentué (U+0061) suivi d'un
code pour l'accent grave (U+0300).

Je n'ai encore jamais vu de logiciel sur Linux ou sur Windows utilisant
autre chose que la forme précomposée quand elle existe. En revanche j'en
ai déjà rencontré sur MacOS (je crois que c'était MacOS 9, pas MacOS X,
mais je n'en suis pas sûr).

Cordialement,
--
Olivier Miakinen

Pourquoi ne pas affecter directement ce caractère à un caractère que vous n'utilisez pas sur votre clavier ? C'est ce que je fais moi-même dans une autre circonstance : utilisant régulièrement les caractères ♭ (bémol) ♯ (dièse) et Δ (pour M7) dans mes textes et courriers ils sont affectés en lieux et places de § µ et £ que je n'utilise jamais

···

Le 24/11/2021 à 17:42, Jean-Paul Quelen a écrit :

L'astuce que j'ai trouvée consiste à taper dans NotePad++ muni du module d'extension HEX-Editor directement les codes hexadécimaux 61 CC 80. Puis je fais un "copier" du caractère puis un remplacement de "à" par ce caractère sous Frescobaldi

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

Du coup (soyons fous !) pourquoi ne pas affecter directement ce
caractère à la touche « à » du clavier ? :slight_smile:

···

Le 24/11/2021 17:57, Vincent Gay a écrit :

L'astuce que j'ai trouvée consiste à taper dans NotePad++ muni du
module d'extension HEX-Editor directement les codes hexadécimaux 61 CC
80. Puis je fais un "copier" du caractère puis un remplacement de "à"
par ce caractère sous Frescobaldi

Pourquoi ne pas affecter directement ce caractère à un caractère que
vous n'utilisez pas sur votre clavier ?

Bonjour,

Pour info, le problème est analysé sur cette page de bogue :

https://gitlab.com/lilypond/lilypond/-/issues/6216

Merci pour l'avoir signalé.

Cordialement,
Jean

Merci à toi pour avoir rédigé le rapport de bug en anglais. Je viens
d'ajouter mon grain de sel, mais je ne serais pas assez confiant en
mon anglais pour rédiger un premier rapport.

Cordialement,

···

Le 26/11/2021 21:25, Jean Abou Samra a écrit :

Pour info, le problème est analysé sur cette page de bogue :

the compiler does not recognize the character "à" (utf8: c3 a0) (#6216) · Issues · LilyPond / LilyPond · GitLab

Merci pour l'avoir signalé.

--
Olivier Miakinen

Non non, c'est bien Jean-Paul qui a signalé le
bug en anglais de lui-même.

Cordialement,
Jean

···

Le 27/11/2021 à 00:30, Olivier Miakinen a écrit :

Le 26/11/2021 21:25, Jean Abou Samra a écrit :

Pour info, le problème est analysé sur cette page de bogue :

the compiler does not recognize the character "à" (utf8: c3 a0) (#6216) · Issues · LilyPond / LilyPond · GitLab

Merci pour l'avoir signalé.

Merci à toi pour avoir rédigé le rapport de bug en anglais. Je viens
d'ajouter mon grain de sel, mais je ne serais pas assez confiant en
mon anglais pour rédiger un premier rapport.

Le 27/11/2021 00:32, Jean Abou Samra m'a répondu :

[...] c'est bien Jean-Paul qui a signalé le
bug en anglais de lui-même.

Ah, en effet.