L'ordinateur

De l'utilité du langage O.D.L. (Organ Definition Langage).

Réflexions informatiques d'un facteur d'orgues.

English version    Deutsche Version    		L'Hydraule



Tout le monde qui s'est peu ou prou un jour frotté à la publication sur le Web connaît les bases du langage HTML. C'est un langage de balisage, c'est-à-dire qu'il parsème le texte qui sera affiché dans les navigateurs des internautes de tags, eux-même non destinés à être affichés mais seulement à mettre en forme le texte qu'ils encadrent. Il faut, pour ceux qui n'en connaissent pas encore le principe (ou pour rafraîchir la mémoire de ceux qui l'aurait oublié) donner un exemple pour bien faire entendre ce fondement dans la publication sur le Web.

Prenons donc l'exemple d'une phrase très simple : « Le nom de la Rose. ». Donnez ce texte pur à un navigateur Web, il l'affichera normalement, dans une police de caractère standard et sans le moindre enrichissement. Si l'on souhaite que le mot « nom » soit affiché en gras (bold en anglais), il est nécessaire de l'encadrer entre deux balises, l'une ouvrante, l'autre fermante, ce qui donne ceci :

Le <b>nom</b> de la Rose. : « Le nom de la Rose. ».

Eut-on voulu de l'italique ou souligner le mot qu'au lieu de placer la balise <b> on aurait choisi <i> pour obtenir de l'italique et <u> pour du souligné (underline en anglais). Bien entendu toute balise normalement ouvrante possède généralement (mais pas toujours) sa réciproque fermante et c'est bien sûr le cas de l'italique du souligné. Certaines balises permettent de changer la couleur des caractères. Elles sont donc de celles qui possèdent un (ou plusieurs) attributs. Ainsi, pour que le mot « Rose » soit réellement affiché en rose, il faut écrire le code HTML :

Le nom de la <font color="pink">Rose</font>. : « Le nom de la Rose. ».

On notera donc qu'il s'agit d'une balise <font>, que celle-ci sert à modifier la police de caractère et qu'elle peut posséder, entre autres, un attribut « color » suivi d'un signe « = » avec une couleur écrite en anglais entre guillemets. Je vous laisse donc comprendre aisément qu'il est possible d'écrire :

Le nom de la <font color="green">Rose</font>. : « Le nom de la Rose. ».

pour passer pour un martien...

Le langage HTML possède un nombre conséquent de balises et il n'est pas ici le lieu d'en faire l'inventaire des noms pas plus que de la spécificité de leur syntaxe. Il est, par contre, nécessaire de bien se rappeler que ce langage fut créé au CERN de Genève en 1989 par Tim Berner Lee. À partir de la fin des années 90 du xxe siècle, on s'est posé la question de la structure-même du langage (en fait, sa syntaxe) et de l'extraordinaire structure arborescente qui en ressortait. De fait, la moindre page Web est d'abord structurée comme une entité HTML, elle même se déclinant entre un en-tête et un corps de texte, ce dernier structuré en paragraphes contenant parfois des enrichissements, &c. L'en-tête du document peut lui-même contenir un titre, des définitions de style, voire des commandes de scripts destinées à agir dynamiquement sur le document pour le modifier par trois clics de souris... Une structure de document HTML peut ainsi prendre la forme :

    <html>
     <head>
      <title>
       Je suis le titre
      </title>
     </head>
     <body>
      <p>
       Je suis un paragraphe avec le mot <font color="pink">Rose</font> en <font color="pink">rose</font>.
      </p>
      <p>
       Je suis un paragraphe avec le mot <i>italique</i> en <i>italique</i>.
      </p>
     </body>
    </html>

On parle de racine (la balise <html>) qui donne lieu à des nœuds et des enfants. Mais le fait que les balises contiennent des mots comme html, head, body, &c, importe finalement moins que la structure arborescente. C'est la raison pour laquelle, l'écriture informatique s'écrit souvent en usant d'indentation, c'est-à-dire de décalage vers la droite des mots en fonction de leur imbrication dans l'arbre. Cette indentation n'est pas prise en compte à la lecture informatique. Par contre, elle permet de mieux lire et comprendre l'imbrication des éléments du langage entre-eux.

Tout les mots des balises font référence à la mise en forme d'un document texte, contenant éventuellement des images, du son ou de la vidéo, mais dont la destination finale est d'abord celle d'un navigateur Web capable de les interpréter et, surtout (puisque c'est le but principal de toutes pages HTML) permettre d'utiliser l'hypertexte afin de relier des documents entre-eux, quel que soit la place physique qu'ils occupent sur les ordinateurs de la planète.

Mais on peut tout à fait imaginer se séparer totalement du vocabulaire propre à HTML pour le remplacer par un autre, inventé de toutes pièces, pour les besoins d'une autre cause que celle d'afficher une page Web mais en conservant la structure arborescente dont tout traitement informatique est si friand. En pratique, cela peut, par exemple, donner ceci :

    <orgue>
     Saint-Hippolyte-du-Fort
     <clavier>
      Grand Orgue
      <jeu>Montre 8'</jeu>
      <jeu>Prestant 4'</jeu>
      <jeu>Flûte 4'</jeu>
      <jeu>Fourniture III-V</jeu>
      <jeu>Bourdon 8'</jeu>
      <jeu>Cornet IV</jeu>
      <jeu>Flûte 8'</jeu>
      <jeu>Trompette 8'</jeu>
     </clavier>
     <clavier>
      Récit
      <jeu>Flageolet 4'</jeu>
      <jeu>Flûte douce 8'</jeu>
      <jeu>Haut-bois 8'</jeu>
      <jeu>Voix-Humaine 8'</jeu>
     </clavier>
     <clavier>
      Pédale
      <jeu>Bourdon 16'</jeu>
      <jeu>Flûte 8'</jeu>
     </clavier>
    </orgue>

Parce que la structure de l'orgue est extrêmement arborescente, parce qu'on peut très bien imaginer décrire de façon beaucoup plus poussée les ramifications de l'arbre (un jeu contient des ensembles de tuyaux — bois, métal, bouché, à cheminée, ouvert —, puis des types de mesures spécifiques &c.), il est possible de décrire à-peu-près tout et n'importe quoi dans notre instrument en suivant ce principe, pour peu que l'on s'attache — quand même — à respecter un vocabulaire de balise défini de manière référentielle (et donc, peu évolutive). On parlera alors de langage XML, dont le premier X de l'acronyme qui le nomme est signifiant d'eXtension, puisqu'on se préoccupe d'abord de la structure plutôt que de la forme. On décline XML en des milliers de façons et ce n'est pas un détail de spécifier ici le format ouvert MusicML qui permet d'écrire de la musique de façon standard.

En termes informatiques, les avantages sont énormes. Le premier qui touchera l'orgue me semble se situer dans la pérennité puisque les documents écrits en XML le sont dans de simples fichiers texte. Le format doit être lisible par l'homme et on doit toujours avoir la possibilité d'en modifier le code manuellement. La simple lecture de la composition d'orgue qui précède démontre qu'un logiciel est capable de lire <clavier> et de le comprendre en tant qu'entité signifiante, c'est-à-dire, exploitable dans des conditions spécifiques au sujet qu'il traite.

Et c'est tout l'intérêt d'un langage de balisage puisqu'outre la signifiance de sa syntaxe, les balises sont, pour un logiciel spécifique, infiniment plus porteuses de sens que ne le sont le contenu des cellules d'un tableur. Plus encore, l'extraordinaire souplesse que permet l'arrangement des données en structure arborescente est infiniment plus performant que les structures tabulaires des bases de données, nettement plus éloignées de la structure-même de notre instrument.

Savoir qu'un premier Do de Montre fait 145 millimètres et que le calcul de progression suit la formule de Cavaillé basé sur la racine quarante-huitième de six est une chose ; échanger des relevés des plans qui soient, sans le moindre problème traduits en anglais, allemand et japonais en est une autre. Nous avons, en Europe, la chance de posséder un patrimoine organologique d'une ampleur que peuvent nous envier les quatre autres continents. Mais nous avons aussi, toujours en Europe, finalement peu de goût pour magnifier nos savoir-faire, préférant souvent laisser s'endormir nos connaissances à l'ombre des bibliothèques, voire perdre nos connaissances acquises puisque l'abondance de notre culture nous permet de briller souvent sans l'ombre d'un effort...

Puisque je crois être le premier (sinon le seul) à m'être penché sur ce problème, le premier exemple signifiant de l'utilisation d'XML en matière de facture d'orgues n'est, curieusement, pas dans la simple mise en base de données de compositions d'orgues mais dans celle, beaucoup plus spécifique, des compositions de plein jeux. La raison en est simple : une composition de plein jeu entraîne, pour le facteur, une réflexion qui peut ne rien avoir d'esthétique mais qui peut être d'ordre purement comptable, donc pratique. Il en va de même au regard de la taille des tuyaux qui, si elle donne une idée musicale de ce vers quoi l'on se dirige, doit pouvoir, pour l'exécutant, être suivi de sa planification pratique. En cela, je crois m'inscrire dans la droite lignée d'un moine bénédictin de la congrégation de Saint-Maur dont l'histoire de la facture d'orgue n'a pas eu qu'à souffrir...

Il y a quelques années maintenant, j'avais donc programmé un utilitaire de facture d'orgues (qui n'était pas exactement mon premier...) et celui-ci avait pour tâche de planifier les tuyaux identiques d'un plein-jeu. La tâche est déjà assez ardue avec un tableur ; elle l'est encore plus avec un navigateur Web dont les formulaires ne sont pas exactement prévus pour traiter des données de facture d'orgues (et on se demande bien pourquoi d'ailleurs)... Mais j'étais quand-même arrivé à produire un programme préféré de certains tuyautier français pour une raison simple : outre le tableau de débit, il dessinait très simplement, et à moindre frais (en art ASCII), le plan du plein jeu. De plus, parce que très didactique, il est très aisé, pour l'apprenti, de comprendre la problématique des plein jeux une fois après en avoir visualisé le plan qui figure chaque tuyau et cet aspect pédagogique des choses, s'inscrivant dans le partage et la continuité des savoirs-faire, était plutôt loin de me déplaire. Bien entendu, là où l'apprenti découvre une disposition pratique, l'expert peut démontrer la présence de masses sonores, privilégiant telle ou telle zone du spectre des fréquences que le simple énoncé de la composition ne donnait pas forcément à comprendre.

Mon utilitaire possédait quelques défauts qu'il fallait corriger (il en possède toujours qu'il faudra affiner mais ils ne sont pas fondamentaux). Il n'était pas polyglotte et demandait de procéder à la saisie des données en deux étapes distinctes (deux pages Web pour produire une troisième, en terme de programmation PHP, c'est beaucoup trop...). Surtout, il ne permettait pas d'enregistrer les données saisie en tant que données structurelle même s'il était, certes, déjà possible de faire une copie des données produites dans plusieurs formats. Mais à aucun moments ceux-ci ne sortaient du schéma de données à publier dans la forme, et non, dans le sens...

« Tempus fugit ». Mais le temps peut, souvent, apporter beaucoup sans le moindre effort. Du strict point de vue de l'évolution des navigateurs Webs et des langages utilisés sur l'Internet, ces dix dernières années n'ont évidemment pas manquées d'être on ne peut plus fécondes. XML, encore très jeune au début des années 2000, celles où je programmais mon utilitaire, n'a pas fait beaucoup de progrès. De toutes façon, pour avoir la vocation d'être verbe (signifiant) avant celle d'être mot (ostensible), XML est si trivial que l'on sait qu'il évoluera peu. Par contre, les langages qui tournent autour et permettent de le traiter ont, eux, énormément évolués ces dernières années. PHP ou JavaScript et surtout la spécification D.O.M. sont devenus des objets avec lesquels on peut aujourd'hui aisément travailler, même si l'on ne pratique, comme c'est mon cas, l'informatique qu'en dilettante et de manière autodidacte.

Recevant un courriel d'un jeune passionné d'orgue me proposant de mettre un lien depuis mon site Web sur le sien, je me rendais compte que la jeune génération (celle à laquelle je n'appartiens plus vraiment...) se posait la question, elle, d'utiliser nettement plus efficacement l'Internet que celle qui la précède. Répondant positivement à cette requête, je me replongeais dans mes notes, parfois très anciennes, mais toujours bien entendu accessibles (l'informatique maîtrisée, cela sert à cela). Outre le fait que, pour en avoir très scrupuleusement pris note, j'avais encore en mémoire les procédures utilisées dans mon utilitaire de débit de plein jeu, j'avais aussi, dans toutes ces années, acquis la certitudes qu'XML pourrait un jour servir à la facture d'orgues, particulièrement dans le stockage des données de restaurations qu'il nous arrive, ici en Europe, et en tant que facteurs d'orgues restaurateurs dignes de ce nom, de publier.

Le courriel de mon jeune passionné d'orgue aura eu l'avantage de me donner envie de remettre mon ouvrage sur le métier. Et je fis, cette fois, aboutir cette programmation-là. Mes trois pages originelles écrites en PHP se réduisirent à une seule, il fut possible d'envisager leur traduction en japonais mais surtout, enfin, un prototype d'O.D.L. se faisait jour avec cette puissance de la démonstration de ses capacités pour peu que l'on se donne la peine d'en réfléchir au sens. Je choisissais évidemment l'anglais comme langue pivot de mes balises mais cela n'a finalement que très peu d'importance de faire une spécification avec la balise <kb> (keyboard) plutôt qu'avec <clavier> ou <werk> puisque les logiciels sont et seront évidemment là pour traduire de manière transparente ces instructions définies dans le langage et présenter les données de façon beaucoup agréable que la lecture d'un code. Dans les faits, il est indéniable que la langue anglaise est particulièrement adaptée pour être récupérée sous forme de code ; mais c'est là un autre débat.

Comme toute mise en place de programme informatique, les choses se sont déroulées par étapes. J'ai d'abord presque totalement réécris mon formulaire pour le rendre nettement plus dynamique, puis permis l'exportation O.D.L. qui n'était pas primitivement programmée. Enfin son importation, celle-là même qui ouvre des portes que j'avais entrevues.

Car une fois réalisée la production logicielle de fichier au format O.D.L., les choses s'accélèrent pour le moins en puissance dans la combinatoire puisqu'il devient possible de :

Sur le site de l'Hydraule, l'adresse URL de mon utilitaire de traitement de plein jeux est :
« http://hydraule.org/bureau/ordi/pleinjeu/pleinjeu.php ».

On télécharge donc le fichier « pleinjeu.php » dans son navigateur. Si l'adresse est donnée telle-quelle, la page s'affiche en français. Il faut spécifier la langue dans l'adresse pour un affichage dans un autre idiome. Pour l'anglais par exemple, l'adresse est :
« http://hydraule.org/bureau/ordi/pleinjeu/pleinjeu.php?l=en ».

Suivant ce principe et en se servant du séparateur additionnel « & », il est possible d'écrire l'URL sous la forme :
« http://hydraule.org/bureau/ordi/pleinjeu/pleinjeu.php?l=en&f=0&url=http://hydraule.org/bureau/ordi/pleinjeu/src/exemples/PJ_STH.odl »

Il y a trois variables qui sont passées dans cette URL au fichier « pleinjeu.php » :

Il faut comprendre que « pleinjeu.php » va chercher le fichier « PJ_STH.odl » qui peut se trouver n'importe où dans le monde et va l'afficher selon un format « f » où :

On imagine la puissance... De touts petits fichiers contenant des données extrêmement calibrées, dans un format lisible par l'homme dans deux cents ans mais lisibles par des logiciels ou des pages Web capables d'en retirer un sens, d'en exploiter les données pour en déduire d'autres, voire même de les croiser...

Car ce n'est pas terminé ; cela ne fait même que commencer...

La lecture du contenu de répertoire de ce serveur permet de se rendre compte que j'ai mis là des exemples de compositions de plein jeu. Un plein jeu ascendant de type germanique, un plein jeu plafonnant de type français, le plein jeu de l'orgue historique de Saint-Hippolyte-du-Fort ainsi que les trois plein-jeu de l'orgue historique d'Auxonne.

Ce dernier est intéressant parce qu'il se répartit sur trois registres distincts, chacun avec sa composition propre. Dans le répertoire du serveur, les fichiers sont naturellement nommés « Aux_PJ_GO.odl » pour le plein jeu de Grand-Orgue, « Aux_FourIII_Pos.odl » pour la Fourniture du Positif et « Aux_CymIII_Pos.odl » pour la Cymbale de ce dernier clavier. Pour chacun d'entre-eux, il est aisé de lire que le code O.D.L. contient bien autant de balises « <RANK></RANK> » que chaque registres contient de rangs soit trois pour les deux registres du Positif et huit pour celui de Grand-Orgue.

L'observation du code O.D.L. du fichier « Aux_Plenum.odl » démontre qu'il ne s'agit que d'une concaténation des données des trois fichiers contenues entre les balises « <MIXTURE></MIXTURE> » et les commentaires ajoutés (dans les balises « <!--  --> » ) permettent, évidemment, d'en faciliter la lecture. Ce n'est donc l'affaire que d'un copier/coller dans un fichier texte ! Et cela permet, à partir d'un fichier de moins de 4 kilos octets de produire ceci ou cela avec une simple combinatoire URL...

La fusion des compositions est donc déjà en partie possible avec un simple éditeur de texte dans la mesure où les reprises déclarées sont identiques d'une composition de plein jeu à l'autre et où la disposition des notes, d'une composition à l'autre, est exactement identique tant dans leur nombres que dans leur « trous » (absence de premier Do#, octave courte, &c.)

La fusion de la composition consiste donc en :

Je n'ai, pour l'instant, pas programmé d'utilitaire capable d'aller chercher plusieurs fichiers distincts sur les disques durs pour les fusionner sans manipulation de code, mais je sais que c'est très simple à faire parce que la lecture d'O.D.L., qui est du pur XML, est extrêmement facile à programmer en PHP. De par sa simplicité, la puissance de ce langage est foudroyante et permettrait aux gens de l'orgue du monde entier d'échanger des données spécifiques sans considération de langue. Il deviendrait possible de créer de manière standard des bases de données de compositions d'orgues dans tous les lieux et toutes les époques, ce qui serait éminemment profitable à tout le monde. Il ne se poserait plus la problématique énorme de l'évolution des standards de tableurs, de base de données ou simplement de logiciels parce que, justement, XML a été conçu pour traverser les siècles.

Cela n'empêcherait en aucune manière de saisir les données sur des logiciels comme M$-Word, M$-Excel ou OpenOffice.org puisque ce genre de logiciel permettent d'en étendre leur capacité par le truchement des macros. Pour les utilisateurs de cette dernière suite bureautique, j'ai déjà prouvé ici à quel point il est aisé de ce servir de la puissance qu'apporte ces logiciels pour produire des données standards et partageables même si je reste convaincu que les formulaires Web présentent l'indéniable avantage de la légèreté dans leur modularité.

Dans tous les cas, il ne ferait aucun problème de récupérer et de fédérer les données déjà établies tant textuelles, iconographiques, sonores ou videos. Les plans d'instruments, pourraient se décliner en SVG qui est un standard déjà établi de graphiques vectoriels, évidemment compatible avec O.D.L. pour être, lui même, du pur XML... Parce que signifiants, les diamètres des tuyaux d'orgues notés dans des fichiers écrits en O.D.L. pourraient induire assez rapidement des grilles de sommier, donc des abrégés. Les fichiers de tailles de tuyaux pourraient se décliner eux-même en fichiers graphiques, telles les abaques de tailles que Dom Bedos gravait sur plaques de cuivre en 1766 par la simple traduction d'O.D.L. au format PDF. Pour avoir été utilisé dans quelques articles sur la l'établissement des tailles de tuyaux, l'utilitaire existe d'ailleurs déjà ; c'est une simple question d'établissement de standards et de l'adaptation de quelques lignes de code...


Mon Dieu, j'ai fais un rêve ; en étiez-vous ?



----------------------------------------------------
                          _
                         | | _
         Sébastien       | || | _
         Matthieu        | || || | _
         Cosson          | || || || | _
         Jacquet         | || || || || | _
                         | || || || || || | _
                         | || || || || || || |
                         | || || || || || || |
          ,-~~-.___.     | || || || || || || |___
         /  | .     \    |_||_||_||_||_||_||_|  /|
        (   )        O   |_||_||_||_||_||_||_| / |
         \_/-. ,----'   / V  V  V  V  V  V  V /  |
            ====      _/____________________ /  /
           /  \-'~;  /|  The Organbuilder   |  /
          /  __/~|  /_|   and his organ     | /
       o=(_______|  |_|_____________________|/
  
  ----------------------------------------------------
           Web: http://www.hydraule.org
        E-mail: smcj@hydraule.org
  ----------------------------------------------------