outil de génération

Bonjour à tous,

Je suis en phase de finalisation d'un générateur de fichier .ly,, écrit
en python 2.4.3 / wxwidgets 2.7, principalement à l'attention des
défricheurs de Lilypond réfractaires à une lecture assidue de la
documentation en anglais.

Ce projet est une bonne idée, qui ressemble au plugin LilyPondTool pour
JEdit, mais sans doute avec l'avantage d'éviter la lourdeur de Java et
par conséquent de JEdit. Si ce projet mûrit suffisament, il pourra
peut-être être distribué avec LilyPond :slight_smile:

À propos, sur la liste lilyond-user est apparu récemment un fil sur
l'utilité d'une interface graphique pour éditer des fichiers ly. Je
partage l'idée de certains selon laquelle une solution efficace serait
un éditeur de texte avancé (coloration syntaxique, compilation et
visualisation depuis l'éditeur, ...), avec des plugins à interface
graphique qui aident à réaliser certaines tâches.

En effet, le format ly est un format texte, donc un éditeur de texte est
naturellement efficace pour le traiter. Les inconvénients d'une
interface graphique excluant le code source sont la perte de vue des
concepts de séparation du contenu musical et de ses options de
formatage. On pourrait également imaginer une solution hybride, comme
certains éditeurs HTML graphiques qui proposent un onglet pour l'édition
visuelle, un onglet pour l'édition du texte source, et un onglet pour la
prévisualisation.

Voilà une très rapide présentation de la question. Qu'en pensez-vous ?

Je joint à ce mail un fichier compressé contenant les scripts et une
documentation

En tant qu'administrateur, je rappelle que les messages de plus de 64 Ko
ne sont pas autorisés sur la liste.

Pour nous faire profiter de ton travail, donne-nous un lien vers un site
où on peut le télécharger. Si tu n'as pas d'espace Web pour ça, il est
tout à fait possible de l'héberger sur
http://lilypondwiki.tuxfamily.org . N'hésite pas à me contacter pour
plus de précisions.

Cordialement

···

Le samedi 04 novembre 2006 à 11:30 +0100, P.E. Brame a écrit :
--
John Mandereau <****@****>

Bonjour à tous,

Je suis en phase de finalisation d'un générateur de fichier .ly,, écrit
en python 2.4.3 / wxwidgets 2.7, principalement à l'attention des
défricheurs de Lilypond réfractaires à une lecture assidue de la
documentation en anglais.

Ce projet est une bonne idée, qui ressemble au plugin LilyPondTool pour
JEdit, mais sans doute avec l'avantage d'éviter la lourdeur de Java et
par conséquent de JEdit. Si ce projet mûrit suffisament, il pourra
peut-être être distribué avec LilyPond :slight_smile:

À propos, sur la liste lilyond-user est apparu récemment un fil sur
l'utilité d'une interface graphique pour éditer des fichiers ly. Je
partage l'idée de certains selon laquelle une solution efficace serait
un éditeur de texte avancé (coloration syntaxique, compilation et
visualisation depuis l'éditeur, ...), avec des plugins à interface
graphique qui aident à réaliser certaines tâches.

En effet, le format ly est un format texte, donc un éditeur de texte est
naturellement efficace pour le traiter.

Le dieux de l'Efficassité, et sa femme la déesse Simplicité, puissent-ils nous préserver d'autre chose.

Les inconvénients d'une
interface graphique excluant le code source sont la perte de vue des
concepts de séparation du contenu musical et de ses options de
formatage. On pourrait également imaginer une solution hybride, comme
certains éditeurs HTML graphiques qui proposent un onglet pour l'édition
visuelle, un onglet pour l'édition du texte source, et un onglet pour la
prévisualisation.

Voilà une très rapide présentation de la question. Qu'en pensez-vous ?

J'ai téléchargé LilyPond hier et jusqu'à présent je n'ai pas été capable de le faire fonctionner. Cela fera peut-être l'ojet de messages ultérieurs (enfin je verrai, car en tant que grand compositeur je vis peut-être dans une sorte d'immanence libérée de la matérialité terrestre). Mais pour autant que je puisse juger de la question d'après mon expérence en matière de traitement de texte mon point de vue ne milite certainement pas en faveur de l'exclusion d'un code source. Cela rendrait la moindre extension plus difficile à écrire et ce n'est pas le seul inconvénient.

Il possible que Word puisse faire tout ce que je fais avec Latex mais je serais bien incapable de dire comment, et je ne risquais pas de le faire à l'époque où j'utilisais Word. L'avantage de Word, on arrive assez bien à utiliser sans documentation, devient vite un sacerdoce si on veux atteindre un minimum de performance. Lorsqu'on à réussi à faire quelque chose d'inhabituel avec Word on n'a pas l'assurance d'être capable de le refaire une seconde fois, alors qu'avec Latex on conserve le code source. Aussi pour rester capable d'utiliser Word efficacement il faudrait le considérer comme une gymnastique qu'on doive s'astreindre à pratiquer régulièrement ; ce qui constituerait peut-être une bonne chose au niveau de l'hygiène de vie, mais aussi une redéfinition du cahier des charges difficile à justifier (on peut trouver mieux dans le genre).

A. H.

···

Le 4 novembre 2006 à 22:14, John Mandereau a écrit :

Le samedi 04 novembre 2006 à 11:30 +0100, P.E. Brame a écrit :

Oui, je suggère un utilitaire avec une séparation verticale vers une fenètre de gauche contenant un éditeur de texte à syntaxe colorée personnalisé pour lilypond,et une fenètre de droite (avec une possibilité de fenètre détachable pour ceux qui préferrent ou qui ont 2 écrans) destinée à contenir l'image de la partition si ça compile, et la fenêtre d'erreur si ça ne compile pas. Un bonton spécialisé permet de lancer la compilation à tout instant. On peut naviguer dans les 2 fenètres. L'idéal serait aussi un bouton pour les synchroniser mais c'est surement plus difficile

Cet outil peut être générique pour beaucoup de langages(latek, éditeur HTML....)

John Mandereau a écrit :

Bonjour à tous,

Ce projet est une bonne idée, qui ressemble au plugin LilyPondTool pour
JEdit, mais sans doute avec l'avantage d'éviter la lourdeur de Java et
par conséquent de JEdit. Si ce projet mûrit suffisament, il pourra
peut-être être distribué avec LilyPond :-)

J'ai utilisé le plugin JEdit (4.2final) pour lilypond, sous windows et sous Linux.
Windows : pas de problèmes particuliers, la barre Lilytools s'affiche correctement
Linux : le plugin est installé mais refuse de s'exécuter !

Limitation sous les 2 OS :

  • l'avancement des développements oblige à travailler avec une version "console" inférieure
  • JEdit est lourd à charger pour le besoin réel

Ce n'est en fait qu'un outil de coloration syntaxique avec auto-complétion, plus une barre d'outils spécifiques permettant :

  • de lancer Lilypond sur le script en cours d'écriture
  • de visualiser le pdf généré (si tout c'est bien déroulé), dans mon cas avec un outil extérieur, donc mon visualisateur de pdf préféré.
    De plus il est en anglais !

Travaillant essentiellement sous Linux, Kate fait aussi bien pour la coloration, la barre d'outils est remplacée par une fenêtre terminal pour exécuter Lilypond (valable aussi sous Win) et une autre pour kpdf (même remarque)

À propos, sur la liste lilyond-user est apparu récemment un fil sur
l'utilité d'une interface graphique pour éditer des fichiers ly. Je
partage l'idée de certains selon laquelle une solution efficace serait
un éditeur de texte avancé (coloration syntaxique, compilation et
visualisation depuis l'éditeur, ...), avec des plugins à interface
graphique qui aident à réaliser certaines tâches.

J'irais faire un tour sur cette liste, aurais-tu un lien direct ? Merci d'avance

En effet, le format ly est un format texte, donc un éditeur de texte est
naturellement efficace pour le traiter. Les inconvénients d'une
interface graphique excluant le code source sont la perte de vue des
concepts de séparation du contenu musical et de ses options de
formatage. On pourrait également imaginer une solution hybride, comme
certains éditeurs HTML graphiques qui proposent un onglet pour l'édition
visuelle, un onglet pour l'édition du texte source, et un onglet pour la
prévisualisation.

Pour moi le process de création d'un document musical sous Lilypond comporte trois phases distinctes :
1 - entrée des mélodies et éventuellement des paroles associées

  • ajout des indications liées aux notes : commentaires, directives d'interprétation
    2 - ordonnancement des entrées : construction des systèmes
  • correction des erreurs
    3 - mise en forme finale : mise en page et titres
  • impression

Mon outil permet de gérer le premier point de la phase 2.
Une solution d'édition purement graphique (comme NVU pour HTML) risque d'alourdir le code généré qui serait alors difficile de maintenir.
De plus l'évolution de la syntaxe même de Lilypond obligerait à sans cesse intervenir dans la solution pour assurer la compatibilité. Sa gestion en fonction des différentes versions utilisées à ce jour (de 2.2 à 2.9) et possibilités de Lilypond accroîtrait encore plus la complexité de cette solution.
J'avais exploré le web pour choisir un éditeur graphique HTML, la majorité des utilisateurs avertis n'en utilisaient pas à cause de la complexité du code généré.

J'avais pensé à un écran de pré-visualisation qui présenterait un schéma du rendu final. Mais les détails seraient cachés, et ce sont eux qui font la différence entre Lilypond et les autres logiciels de création musicale. De plus il implique l'utilisation d'un bibliothèque graphique multi-OS, donc un axe de maintenance et de "versionning" supplémentaire, sans compter l'aspect documentaire minimal : tout le monde n'a pas l'ADSL, ni les compétences informatiques pour installer de nouvelles applications.
La logique de construction des blocs permet d'avoir un aperçu mental du résultat final.

En tant qu'administrateur, je rappelle que les messages de plus de 64 Ko
ne sont pas autorisés sur la liste.

Le fichier joint "pèse" 61,7 ko, je dois dépasser de peu la limite.

Ci-joint les fichiers scripts, je joins la doc au format texte (donc sans les copies écran). Je vais regarder du coté de tuxfamiliy pour un hébergement éventuel.
Note importante :
La première ligne du fichier "script_lily.py" doit être adaptée : elle doit indiquer où se trouve physiquement "python".
Sous Win se serait du style c:\program files...\python ou dans l'arborescence de Lilypond (un python est livré avec)

John Mandereau a écrit :

doc.txt (2.22 KB)

code_score.zip (7.01 KB)

Bonjour,

Je reprends clavier et écran.

Ci-joint les scripts refusés ? par l'outil de gestion des messages de la liste.
Le fichier score_lily.py contient le point d'entrée (main)

Bonne journée

P.E. Brame

****@**** a écrit :

score.py (9.03 KB)

score.pyc (8.38 KB)

score_lily.py (7.41 KB)

Limitation sous les 2 OS :
- l'avancement des développements oblige à travailler avec une version
"console" inférieure
- JEdit est lourd à charger pour le besoin réel

Ce n'est en fait qu'un outil de coloration syntaxique avec
auto-complétion, plus une barre d'outils spécifiques permettant :
- de lancer Lilypond sur le script en cours d'écriture
- de visualiser le pdf généré (si tout c'est bien déroulé), dans mon
cas avec un outil extérieur, donc mon visualisateur de pdf préféré.
De plus il est en anglais !

Il est donc clair que JEdit n'est pas une solution idéale.

J'irais faire un tour sur cette liste, aurais-tu un lien direct ?
Merci d'avance

The importance of a graphical interface :
http://lists.gnu.org/archive/html/lilypond-user/2006-10/msg00446.html
avec en bas de la page l'arbre des réponses...

À signaler aussi :
http://news.gmane.org/index.php?prefix=gmane.comp.gnu.lilypond est une
autre archive des listes de LilyPond, avec une interface différente.

Pour moi le process de création d'un document musical sous Lilypond
comporte trois phases distinctes :
1 - entrée des mélodies et éventuellement des paroles associées
    - ajout des indications liées aux notes : commentaires, directives
d'interprétation
2 - ordonnancement des entrées : construction des systèmes
    - correction des erreurs
3 - mise en forme finale : mise en page et titres
   - impression

Mon outil permet de gérer le premier point de la phase 2.
Une solution d'édition purement graphique (comme NVU pour HTML) risque
d'alourdir le code généré qui serait alors difficile de maintenir.
De plus l'évolution de la syntaxe même de Lilypond obligerait à sans
cesse intervenir dans la solution pour assurer la compatibilité. Sa
gestion en fonction des différentes versions utilisées à ce jour (de
2.2 à 2.9) et possibilités de Lilypond accroîtrait encore plus la
complexité de cette solution.
J'avais exploré le web pour choisir un éditeur graphique HTML, la
majorité des utilisateurs avertis n'en utilisaient pas à cause de la
complexité du code généré.

Effectivement. Je n'y connais quasiment rien, mais je dirais qu'il est
difficile d'écrire des programmes qui génèrent du code avec autant de
subtilité que pourrait le faire un programmeur humain.

J'avais pensé à un écran de pré-visualisation qui présenterait un
schéma du rendu final. Mais les détails seraient cachés, et ce sont
eux qui font la différence entre Lilypond et les autres logiciels de
création musicale.

Tout à fait d'accord.

De plus il implique l'utilisation d'un bibliothèque graphique
multi-OS, donc un axe de maintenance et de "versionning"
supplémentaire, sans compter l'aspect documentaire minimal : tout le
monde n'a pas l'ADSL, ni les compétences informatiques pour installer
de nouvelles applications.

Ce sont de gros problèmes en effet (désolé de sortir du sujet de la
discussion, et même de la liste...)
Au niveau des bibliothèques graphiques multi-OS, je n'ai entendu parler
que de Java - qui consomme pas mal de ressources - et de wxWidgets - je
ne connais pas assez pour juger.
La possibilité et la facilité d'accès aux logiciels est un autre gros
problème. Des solutions existent, mais requièrent l'ADSL ou des
compétences informatiques : les dépôts RPM sous GNU/Linux requièrent
l'ADSL ; l'installation et la maintenance de logiciels sous Windows (qui
se fait forcément un par un à ma connaissance) requièrent des
compétences informatiques - ou alors le système est vite saturé et
pollué, vive la réinstallation !

La logique de construction des blocs permet d'avoir un aperçu mental
du résultat final.

C'est justement cet aspect qui devrait tout le temps apparaître dans un
éditeur, et cela est plus difficile dans une interface graphique. Rêvons
un peu : et si un éditeur graphique affichait chaque expression musicale
comme des notes sur une portée, dans une petite boîte, et que ces boîtes
s'imbriquent dans des boîtes comme des poupées russes, reflétant la
structure d'une cource LilyPond ?

Ci-joint les fichiers scripts, je joins la doc au format texte (donc
sans les copies écran). Je vais regarder du coté de tuxfamiliy pour un
hébergement éventuel.

Pour info, Tuxfamily héberge déjà deux sites à propos de LilyPond, et
ils ne connaissent pas un développement particulièrement fulgurant :
- un wiki http://lilypondwiki.tuxfamily.org
- un site créé de toutes pièces par Gauvain Pocentek
http://gnu-pond.tuxfamily.org/

···

Le dimanche 05 novembre 2006 à 13:57 +0100, P.E. Brame a écrit :

--
John Mandereau <****@****>

> En effet, le format ly est un format texte, donc un éditeur de texte est
> naturellement efficace pour le traiter.
Le dieux de l'Efficassité, et sa femme la déesse Simplicité, puissent-ils
nous préserver d'autre chose.

:slight_smile:

J'ai téléchargé LilyPond hier et jusqu'à présent je n'ai pas été capable de
le faire fonctionner. Cela fera peut-être l'ojet de messages ultérieurs
(enfin je verrai, car en tant que grand compositeur je vis peut-être dans
une sorte d'immanence libérée de la matérialité terrestre).

LilyPond n'a certainement pas encore été assez testé : à l'approche de
l'annonce de la version 2.10, beaucoup de bugs sont encore rapportés. Ce
n'est pas le signe que LilyPond est particulièrement buggé -- tous les
logiciels le sont -- mais plutôt que des utilisateurs rapportent les
problèmes. L'équipe de développement de LilyPond n'a pas les moyens de
payer des testeurs.

La version 2.6 a connu quelques semaines après sa sortie quelques
dizaines de milliers de téléchargements. Sur ces téléchargements,
combien d'utilisateurs ont rencontré un problème critique d'installation
ou de mise en route ? Combien se sont heurtés à de grandes difficultés ?
Combien ont abandonné ? Ou encore combien l'ont téléchargé juste pour
voir, sans savoir ce que c'est ?

Les retours des nouveaux utilisateurs sont d'une aide précieuse.

Mais pour autant
que je puisse juger de la question d'après mon expérence en matière de
traitement de texte mon point de vue ne milite certainement pas en faveur de
l'exclusion d'un code source. Cela rendrait la moindre extension plus
difficile à écrire et ce n'est pas le seul inconvénient.

Il possible que Word puisse faire tout ce que je fais avec Latex mais je
serais bien incapable de dire comment, et je ne risquais pas de le faire à
l'époque où j'utilisais Word. L'avantage de Word, on arrive assez bien à
utiliser sans documentation, devient vite un sacerdoce si on veux atteindre
un minimum de performance. Lorsqu'on à réussi à faire quelque chose
d'inhabituel avec Word on n'a pas l'assurance d'être capable de le refaire
une seconde fois, alors qu'avec Latex on conserve le code source. Aussi pour
rester capable d'utiliser Word efficacement il faudrait le considérer comme
une gymnastique qu'on doive s'astreindre à pratiquer régulièrement ; ce qui
constituerait peut-être une bonne chose au niveau de l'hygiène de vie, mais
aussi une redéfinition du cahier des charges difficile à justifier (on peut
trouver mieux dans le genre).

Je partage exactement la même expérience là-dessus.

···

Le dimanche 05 novembre 2006 à 12:25 +0100, André Hetzel a écrit :

Le 4 novembre 2006 à 22:14, John Mandereau a écrit :

--
John Mandereau <****@****>

Bonjour,

Le 5 novembre dernier j'avais envoyé ce message, dont les pièces jointes avaient été refusées. J'ai appris que le serveur était malade... Est-il guéri maintenant ?

Note : le wiki refuse toujours les "uploads" (cf lien de John)
Je les ai envoyé à Gauvain, (****@****) pour le diffuser sur son blog sur lilypond, adresse dans le thread de la liste

Merci de votre accueil

P.E. Brame

score.py (9.04 KB)

score.pyc (8.38 KB)

score_lily.py (7.41 KB)