Sommaire
Introduction
Pour créer des partitions musicales, il existe un excellent logiciel appelé LilyPond qui, en gros, est à MuseScore ou Finale ce que TeX est à LibreOffice Writer ou Microsoft Word.
LilyPond prend en entrée un fichier texte que vous pouvez aisément manipuler à l'aide de votre éditeur de texte favori. Il existe néanmoins Frescobaldi qui facilite l'édition de fichiers LilyPond au point de pouvoir être considéré, en paraphrasant, comme une sorte d'EDI pour Lilypond.
On peut également utiliser un logiciel comme Denemo ou Rosegarden pour saisir de la musique via une interface graphique ou un périphérique d'entrée MIDI, voire une entrée audio, et générer le fichier LilyPond correspondant.
Jusqu'à présent, j'utilisais un petit utilitaire de ma création dans lequel on saisit, dans un premier temps, des notes avec un clavier MIDI pour, dans un second temps, leur affecter une durée, comme détaillé ici-même.
Cependant, son interface étant textuelle, cet utilitaire s’avérait assez peu pratique par certains aspects. J'ai donc essayé Denemo, avec lequel on est censé pouvoir faire la même chose avec une interface graphique. Ça doit être faisable, mais je n'ai pas trouvé comment le faire facilement. Ajoutez à cela une certaine propension du logiciel au plantage, et vous comprendrez que je n'ai pas insisté.
Donc, j'ai repris mon petit utilitaire, et je lui ai ajouté une interface graphique, ce qui donne ça :
Il est loin d'être complet (voir la section Améliorations possibles ci-dessous) mais il est néanmoins suffisamment fonctionnel pour un usage basique.
Installation
NOTA : pour essayer le logiciel sans avoir à l'installer, c'est par ici (bouton Run, un peu de patience, puis clic sur l'URL) : https://q37.info/s/tpp7ckkv.
Pour compiler ce logiciel, il faut :
- la commande GNU make ;
- un compilateur C++ ;
- la bibliothèque ALSA avec ses fichiers de développement (libasound-dev).
Pour la compilation proprement dite :
- récupérer le contenu du dépôt https://github.com/epeios-q37/faasq ;
- de l'intérieur de ce dépôt, lancer la commande
make
(génération defaasq
) ; - récupérer le contenu du dépôt https://github.com/epeios-q37/msfgqxdh ;
- de l'intérieur de ce dépôt, lancer la commande
make
(génération delibmsfgqxdh.so
).
Pour lancer l'application, se placer dans le répertoire msfgqxdh
, puis lancer : <chemin-vers>/faasq ./msfgqxdh
. En supposant que les deux dépôts ci-dessus soient dans le même répertoire, en étant placé dans le répertoire du dépôt msfgqxdh
, cela donne : ../faasq/faasq ./msfgqxdh
.
Pour que les scripts fournis avec le logiciel fonctionnent (voir section dédiée plus bas), il faut que lilypond et xsltproc soient installés et accessible via le PATH.
Si vous voulez déplacer les exécutables, il faut veiller à ce que les fichiers suivants soient dans le même répertoire que l'exécutable concernés :
- pour
faasq
:faasq.xcfg
etfaasq.xlcl
; - pour
libmsfgqxdh.so
:msfgqxdh.xcfg
,msfgqxdh.xlcl
etxmld2ly.xsl
.
Interface
L'interface est découpée en zones dont voici la description :
-
Midi in (
Parameters/Devices/In
) :- les dispositifs d'entrée MIDI connectés au système apparaissent ici, le bouton Grab permet d'activer celui sélectionné,
- le bouton Grab permet également à la session en cours d'utilisation de capturer les évènements MIDI issus du périphérique ;
-
Key (
Parameters/Signature/Key
) : le nombre de dièses ou de bémols de l'arm(at)ure ; -
Time (
Parameters/Signature/Time
) : métrique de la mesure : - Score/Preview : aperçu du fragment musical ;
- Score/Duration/Rest : permet diverses modifications de la note sélectionnée (on peut également utiliser des raccourcis clavier) ;
-
Score/Width (
Parameters/Width
) : nombre de notes par portée de l'aperçu ci-dessus ; - Score/(dernière zone) : permet de déplacer le curseur (on peut aussi cliquer sur une note), et d'effacer une ou l'ensemble des notes ;
- Audio : permet de piloter le lecteur audio ;
- Keyboard : clavier virtuel, qui peut être caché ; s'il y a un dispositif d'entrée MIDI connecté au système, ce clavier est caché par défaut ;
-
Scripts (
Definitions/Scripts/Script
) : permet de lancer les différents scripts qui sont définis dans la configuration (voir section suivante), et dont le résultat est affiché dans Output, sauf si Embedded est décoché, auquel cas ce résultat s'affiche dans une nouvelle page.
Les scripts
Les boutons de la zone Scripts sont générés à partir de la section Definitions/Scripts
du fichier de configuration msfgqxdh.xcfg
. Voilà le contenu de cette section correspondant à l'illustration ci-dessus :
<Scripts>
<Script
id="_ABC"
Label="ABC (debug)"
Mime="text/plain"
># Built-in script. 'id' value of '_ABC' is reserved.</Script>
<Script
id="text"
Label="XML (as text)"
Mime="text/plain"
>while read x ; do echo $x ; done | base64</Script>
<Script
id="xml"
Label="XML"
Mime="text/xml"
>while read x ; do echo $x ; done | base64</Script>
<Script
id="xsl"
Label="XSL"
Mime="text/xml"
>base64 ./xmld2ly.xsl</Script>
<Script
id="ly"
Label=".ly"
Mime="text/plain"
>xsltproc "./xmld2ly.xsl" - | base64</Script>
<Script
id="png"
Label="PNG"
Mime="image/png"
>xsltproc "./xmld2ly.xsl" - | lilypond --png -o msfgqxdh.tmp - ; base64 ./msfgqxdh.tmp.png ; rm msfgqxdh.tmp*</Script>
<Script
id="pdf"
Label="PDF"
Mime="application/pdf"
>xsltproc "./xmld2ly.xsl" - | lilypond -o msfgqxdh.tmp - ; base64 ./msfgqxdh.tmp.pdf ; rm msfgqxdh.tmp*</Script>
</Scripts>
Le contenu de la section Output correspondant à l'illustration ci-dessus a été généré avec le bouton PDF.
Une fois satisfait par le résultat, on affichera les notes au format Lilypond à l'aide du bouton .ly, que l'on pourra alors copier/coller.
La balise Script
contient le script à exécuter, et a pour attributs :
-
id
, dont la valeur est libre, mais qui doit être unique ; -
Label
, dont la valeur sera utilisée comme libellé du bouton ; -
Mime
, dont la valeur doit correspondre au type MIME du contenu généré par le script.
Les scripts reçoivent sur l'entrée standard un flux XML décrivant les notes saisies, et doivent générer sur la sortie standard un contenu en base64, d'où la présence de la commande homonyme dans les scripts.
Améliorations possibles
Musique
- Gestion des tuplets (duolet, triolet…) ;
- gestion des accords ;
- gestion des anacrouses ;
- choix de la figure de note par défaut autre que la noire ;
- choix d'une clef autre que celle de sol.
Paramètres
Les valeurs par défaut de certains composants de l'interface graphique peuvent être définis dans la section Parameters
du fichier de configuration msfgqxdh.xcfg
. Les balises correspondantes sont précisées entre parenthèses dans la section Interface ci-dessus.
Il faudrait rendre cela possible pour d'autres composants de l'interface.
En outre, il existe un mécanisme qui permet de surcharger certaines valeurs de la configuration avec des arguments de la ligne de commande (voir https://q37.info/computing/epeios/configuration). Ce mécanisme ne fonctionne actuellement pour la configuration d'une bibliothèque dynamique.
Fichier de configuration
Le procédure de publication du logiciel stocke actuellement la configuration dans un seul fichier (msfgqxdh.xcfg
), mais cette dernière est en réalité constituée de plusieurs fichiers, qui contiennent des instructions qui sont traitées par un préprocesseur XML. Ainsi, voici la section Scripts
ci-dessus avant son passage par le préprocesseur :
<Scripts>
<xpp:bloc>
<xpp:ifeq select="prod" value="no">
<xpp:define name="xmld2ly">
<xpp:bloc>/home/csimon/hg/epeios/stable/xmld2ly.xsl</xpp:bloc>
</xpp:define>
</xpp:ifeq>
<xpp:ifeq select="prod" value="yes">
<xpp:define name="xmld2ly">
<xpp:bloc>./xmld2ly.xsl</xpp:bloc>
</xpp:define>
</xpp:ifeq>
<xpp:define name="LilyCommon">
<xpp:bloc>
<xpp:bloc>xsltproc "</xpp:bloc>
<xpp:expand select="xmld2ly"/>
<xpp:bloc>" - | lilypond</xpp:bloc>
</xpp:bloc>
</xpp:define>
<xpp:define name="Base">
<xpp:bloc>while read x ; do echo $x ; done | base64</xpp:bloc>
</xpp:define>
</xpp:bloc>
<Script id="_ABC" Label="ABC (debug)" Mime="text/plain">
<xpp:bloc># Built-in script. 'id' value of '_ABC' is reserved.</xpp:bloc>
</Script>
<Script id="text" Label="XML (as text)" Mime="text/plain">
<xpp:expand select="Base"/>
</Script>
<Script id="xml" Label="XML" Mime="text/xml">
<xpp:expand select="Base"/>
</Script>
<Script id="xsl" Label="XSL" Mime="text/xml">
<xpp:bloc>base64 </xpp:bloc>
<xpp:expand select="xmld2ly"/>
</Script>
<Script id="ly" Label=".ly" Mime="text/plain">
<xpp:bloc>xsltproc "</xpp:bloc>
<xpp:expand select="xmld2ly"/>
<xpp:bloc>" - | base64</xpp:bloc>
</Script>
<Script id="png" Label="PNG" Mime="image/png">
<xpp:expand select="LilyCommon"/>
<xpp:bloc> --png -o msfgqxdh.tmp - ; base64 ./msfgqxdh.tmp.png ; rm msfgqxdh.tmp*</xpp:bloc>
</Script>
<Script id="pdf" Label="PDF" Mime="application/pdf">
<xpp:expand select="LilyCommon"/>
<xpp:bloc> -o msfgqxdh.tmp - ; base64 ./msfgqxdh.tmp.pdf ; rm msfgqxdh.tmp*</xpp:bloc>
</Script>
</Scripts>
Il faudrait donc améliorer la procédure de déploiement pour conserver le découpage en plusieurs fichiers, ainsi que les instructions préprocesseurs utiles (possibilité de définir des scripts différents en fonction de la plateforme d'exécution, par exemple).
Astuce
L'encombrement et/ou la disposition du périphérique d'entrée MIDI sont parfois tels qu'il n'est pas facile d'utiliser ce périphérique et d'avoir en même temps accès à l'écran et/ou au clavier de l'ordinateur sur lequel le périphérique est connecté. Dans ce cas, vous pouvez avoir accès à l'interface du logiciel à partir d'un smartphone ou d'une tablette en scannant le code QR généré par le logiciel. Pour un fonctionnement correct, il est alors nécessaire de cliquer sur le bouton Grab.
# Et Frescobaldi ?
Posté par jeanas (site web personnel, Mastodon) . Évalué à 10.
C'est super d'entendre parler de LilyPond sur ce site !
(Pour info, je suis développeur actif de LilyPond.)
Par curiosité : j'imagine que vous avez dû essayer aussi la fonction d'entrée MIDI proposée par Frescobaldi, en quoi était-elle insuffisante ? Qu'est-ce qui vous a poussé à créer cet outil perso ?
[^] # Re: Et Frescobaldi ?
Posté par Claude SIMON (site web personnel) . Évalué à 7.
Puisque l'occasion m'en ai donné, un grand merci, qui englobe naturellement tout les autres contributeurs, pour ce fantastique logiciel. En tant que musicien, j'ai souvent affaire à des partitions vendues fort chers par des éditeurs ayant pignon sur rue, et souvent, quand je vois leur rendu, je me demande «Pourquoi diable n'utilisent-t-ils pas LilyPond ?».
Lilypond a déjà fait l'objet de plusieurs publications ici-même, mais c'est quand même un logiciel dont la plupart des personnes fréquentant ce site, comme dans le reste de la population, n'ont pas l'usage.
Concernant Frescobaldi, celui-ci ne gère que la saisie des notes, ce qui n'est qu'une des fonctionnalités de mon outil. Avec ce dernier, une fois les notes saisies, on se repositionne sur la première note, puis on saisit la durée de chaque note, à l'aide du clavier ou des boutons adéquats. Cette fonctionnalité n'est pas disponible avec Frescobaldi, comme semble le confirmer cette entrée GitHub non close.
Ceci dit, il y a une fonctionnalité qui s'en rapproche, avec
Tools/Rythm/Apply rythm…
, qui ouvre une boîte de dialogue dans laquelle on saisit les durées au format Lilypond, qui sont alors appliquées une à une aux notes sélectionnées. Mais c'est un peu moins pratique parce que, par exemple, une noire suivie d'une croche suivie d'une double-croche nécessitent de taper la séquence de touches 4[espace]8[espace]16, alors qu'avec mon outil il suffit de la séquence 345 (ou de cliquer sur les boutons correspondants).Je viens de trouver une vidéo qui montre comment fonctionne Denemo. Si j'avais vu cette vidéo plus tôt, peut-être que je n'aurais pas crée mon outil. Ce qui m'avait échappé avec Denemo, c'est qu'il faut d'abord saisir le rythme, puis les notes, alors que j'étais parti sur principe de d'abord saisir les notes, puis le rythme, principe appliqué dans mon outil.
Cependant, Denemo est conçu pour prendre en charge l'intégralité de l'écriture d'une partition, dans l'idée, je pense, de se positionner comme alternative à Finale. Il a son propre format de fichier, et LilyPond ne lui sert que de moteur de rendu. Or, je préfère travailler directement sur des fichiers LilyPond, ce qui est facilité avec Frescobadi, et mon outil, comme le suggère le titre du journal, est conçu dans l'idée être utilisé en complément.
Et encore merci pour ce logiciel :-) !
Pour nous émanciper des géants du numérique : Zelbinium !
# Saisie des notes puis durée
Posté par raphj . Évalué à 5. Dernière modification le 25 mars 2023 à 12:22.
Ayant saisi quelques partitions ces derniers temps avec MuseScore, parfois avec un clavier MIDI, ça me manque de pouvoir saisir toutes les notes, et ensuite déterminer leur durée. Je trouve ça ultra fastidieux de saisir des notes en devant sans cesse faire des aller-retours entre le clavier MIDI et le clavier et/ou la souris, d'autant qu'il y a des bugs liés à la disposition AZERTY et plus généralement à la saisie clavier [1,2] dans MuseScore qui empêchent certains raccourcis clavier de fonctionner (correctement).
Ton journal est un bon rappel que LilyPond existe, je pense que je vais essayer de m'y mettre, et je vais essayer ton outil. J'essaierai aussi Frescobaldi.
Comment ça se passe pour les silences ? Joues-tu une note puis tu la transforme en silence ? Ajoutes-tu les silences en saisissant les durées ? Autrement ?
Merci !
[1] https://github.com/musescore/MuseScore/issues/17010
[2] https://github.com/musescore/MuseScore/issues/14195
[^] # Re: Saisie des notes puis durée
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Comme montré dans la vidéo mentionnée dans mon précédent commentaire, Denemo offre la possibilité de saisir le rythme au clavier d'ordinateur, puis de saisir les notes au clavier MIDI. Ça peut être une solution, sauf que je ne vois pas trop comment récupérer de manière simple ce qui a été saisi pour l’intégrer à MuseScore.
Avec mon outil, c'est l'inverse : on saisit d'abord les notes, puis les durées correspondantes. Ceci dit, il serait relativement simple d'implémenter la saisie à la sauce Denemo. On récupère ensuite ce qui a été saisi au moyen d'un copier/coller de ce qui est généré par un appui sur le bouton .ly. C'est au format LilyPond, mais on peut générer n'importe quel format textuel avec le fichier XSL et le script adéquats, sur le modèle de ce qui est fait avec le format LilyPond. Mais, là encore, je ne vois pas trop quel format utiliser pour MuseScore et comment y intégrer les données.
Pour les silences, on saisit une note quelconque à la place du silence. Ensuite, quand on est dans la phase de saisie des durées, une fois le curseur positionné sur la note, on la marque comme un silence (touche 0), on revient sur la note (on peut utiliser la flèche gauche du clavier), puis on saisit la durée du silence. Ou inversement : on saisit la durée, on revient sur la note, puis on la marque comme silence. Ce n'est pas très optimisé ; peut-être que le mieux c'est que le fait de marquer une note comme silence ne fasse pas avancer le curseur…
Personnellement, je préfère travailler directement avec des fichiers texte, comme l'autorise LilyPond, plutôt qu'avec des applications WYSIWYG comme MuseScore ou Finale. On a beaucoup plus de liberté : on peut créer des petits utilitaires comme mon outil, ou des logiciels plus complets comme Frescobaldi, voire Denemo et ainsi créer son propre flux de travail. J'avais déjà eu la même démarche avec Markdown/Marp.
Pour nous émanciper des géants du numérique : Zelbinium !
# Utiliser localement ?
Posté par raphj . Évalué à 2. Dernière modification le 31 mars 2023 à 14:03.
Je viens d'essayer de compiler et démarrer l'application. J'ai été surpris de voir que ça se lançait en local mais qu'il fallait y accéder à partir d'une URL externe.
Peux-tu en dire plus sur pourquoi et s'il y a moyen de le lancer sans connexion internet ? Je suppose que la page utilise des capacités présentes uniquement en HTTPS et que ça simplifie l'installation, mais ça serait cool de pouvoir utiliser sa propre infrastructure quand on a déjà un serveur web avec du HTTPS quelque part.
Plus généralement l'architecture de ton projet semble intéressante, avec les problèmes qu'elles résout, peut-être que tu peux répondre avec un journal ?
Les README des deux dépôts que tu nous fait cloner sont un peu avares en détails, voire inexistants.
[^] # Re: Utiliser localement ?
Posté par Claude SIMON (site web personnel) . Évalué à 3.
L'application s'appuie, pour l'interface graphique, sur le toolkit Atlas dont le but, en gros, est de pouvoir profiter de certaines technos web (HTML/CSS) sans en subir les inconvénients (JavaScript, nécessité de disposer d'un serveur web).
L'ancêtre du toolkit Atlas s’appuyait sur Electron et, avant cela, sur XULRunner. C'est pour éviter cela que le toolkit s'appuie sur un serveur, avec lequel il communique à l'aide d'un protocole maison. L'URL affichée au démarrage de l'application lance une connexion à ce même serveur, mais en utilisant le protocole HTTP(S), donc avec un navigateur web comme client.
Voici le schéma correspondant :
On peut mettre en place son propre serveur en suivant la procédure à l'adresse https://q37.info/s/hxkfph74.
L'application fonctionne également en HTTP, mais j'ai remarqué que certains opérateurs téléphoniques bloquaient les WebSockets en HTTP, d'où l'utilisation de HTTPS par défaut.
Il y a déjà eu ici même quelques publications concernant cette architecture : https://linuxfr.org/tags/atlas_toolkit/public. Mais s'il y a des aspects à approfondir, je le ferais bien volontiers, éventuellement sous forme de journal…
Pour nous émanciper des géants du numérique : Zelbinium !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.