Pour ou contre

Les difficultés rencontrées par les personnes qui tendent de pratique un langage de composition musicale apparu il y a quelques années, le système Grace, m’incite à donner mon point de vue. Ces diffultés sont surtout inhérentes au lange Lisp et à l’un de ses succédanés, le Scheme.

Le projet Grace de Heinrich Taube est, entre autres, une interface avec le langage CSound qui permet de jouer de la musique en temps réel à coups de Scheme et de MIDI. À mon avis, on cumule les handicaps:

Les controverses absentes

Dans cette page, il est question de quelques controverses tues:

  • quel est l’avantage esthétique de la non-composition ce qui est synonyme de pratique du temps réel;
  • qu’apportent les langages obscurs et difficiles (ex. Lisp, Scheme, Haskell, OCaml etc.) par rapport aux langages (relativement nouveaux) tels que Python ou Ruby;
  • pourquoi préférer le mélange des langages (Scheme + C++, Python + Lisp, etc.) à un seul langage;
  • faut-il continuer à pratiquer des syntaxes vétustes issues des projets Music xx remontant aux années 1950 ?

Le mélange des langages

L’argument principal de ceux qui pratiquent le mélange des langages consiste à prétendre qu’on combine ainsi les avantages de deux ou plusieurs langages ou qu’un langage vient en supplément d’un premier langage car celui-ci ne permet pas certaines déroulements ou ne dispose pas de certaines fonctions.

Je prétends que si un langage ne dispose pas de certaines fonctions - quelle que soit son efficacité dans d’autres domaines - il vaut mieux l’abandonner complètement et définitivement en choisissant le langage le plus évolué qui contient toutes les fonctions (je l’ai fait plusieurs fois).

Ces conseiles ne sont pas adressés aux informaticiens construisant un logiciel fermé mais aux usagers pour lesquels l’informatique n’est pas le foyer de leur activité mais seulement un outil.

Scheme, Lisp et les autres

Les langages adoptant la syntaxe du Lisp mettent chaque opération entre une parenthèse ouvrante et une parenthèse fermante, le nom de l’opération est en première position suivi par l’énumération des arguments; ainsi l’addition s’écrit

(+ nombre0 nombre1, ....)

En langage algébrique habituel on écrit

(nombre0 + nombre1 + )

ce qui est conforme à nos habitudes mathématiques.

Les arguments que la notation lispienne est plus proche de notre structure mentale qui veut «additionner ça et ça et ça» ou plus proche de la structure informatique des piles (stacks) ne tiennent pas: nous avons l’habitude de la notation algébrique qui a fait ses preuves d’efficacité et, en outre, nous n’avons pas à être les servants d’une machine comme cela devait être en 1950.

Les langages lispiens ont certains avantages. Ainsi le projet Common music notation (CMN) de Bill Schottstaedt est un outil aussi efficace qu’élégant de la musique instrumentale occidentale. Là où Lilypond a besoin de 1.1 Go, CMN se contente de 7.3 Mo ! ce qui conforte ma thèse de l’efficacité d’un langage unique (dans ce cas le Lisp). Toutefois les tours de gymnastique nécessaires pour noter des polyphonies sur une seule portée contrastent singulièrement avec la facilité de Lilypond.

Pour ce qui est de la notation de la musique de la nouvelle musique du 20e siècle, les deux systèmes, Lilypond et CMN, sont également manchots. Par contre la syntaxe de Lilypond est d’une stupéfiante incohérence. On peut donc en conclure que les deux projets sont quelque peu mal conçus au départ. La jungle lilypondienne est difficile à pénétrer (Scheme en fait partie avec d’autres langages); la jungle lispienne l’est tout autant.

Le «temps réel»

La lutherie électronique n’est pas ou n’est pas encore un domaine aussi réactif que la lutherie mécanique. Le nombre énorme de paramètres agissant simultanément pour former un son de violon requiert autant d’interfaces (ou prothèses) que l’industrie électronique n’est pas en mesure de fournir car elle a bien d’autres centres d’intérêt (armement, surveillance, espionnage etc.).

La fétichisation de l’interprétation telle qu’elle a envahi l’État musical actuel a contribué à transférer la notion de temps réel - en usage dans l’univers militaire, industriel et commercial - dans le domaine esthétique, mais avec aucun autre résultat que de piètres résultats allant d’une frustration à la suivante, car, on sait toujours pourquoi ça n’a pas bien marché, mais la prochaine fois ça ira mieux. Le temps réel n’est pas un critère esthétique, mais une étiquette médiatique qui peut lever des fonds pour la recherche avec une garantie de réel échec.

L’originalité de la musique pour haut-parleurs réside dans la possibilité de concevoir et réaliser des objets musicaux humainement injouables.

Ceci, il est certain que l’auscultation de corps résonnants physiques par microphonie, modulation, filtrage et amplification fait partie de l’acquis esthétique de la musique du 20e siècle - mais cela n’a preque rien à voir avec la composition musicale par algorithmes.

De quelques vétustés

Les objets vétustes ont la vie dure, c’est bien connu. Il s’agit de voir qui dénote quoi de vétuste et pour quelles raisons.

Le format et les logiciels MIDI apportent des aides puissantes à la production industrielle de musique. Mais mettent autant d’obstacles sur le chemin de celui qui veut ne pas se soumettre à ces normes industrielles. S’il y a un avenir pour la musique, ce n’est pas dans le cadre des MIDI. C’est pourquoi le format est vétuste et obsolète.

Csound constitue le fondement du projet Grace. Or la syntaxe de CSound remonte aux syntaxes des différents projets Music I (1957), Music II (1958), Music III (1958), Music IV (1962) d’abord écrits en assembleur, puis en FORTRAN à partir de Music V. Ce n’est pas l’âge qui fait la vétusté de ces projets, mais leur syntaxe: chaque ligne significative est écrite sur le modèle:

opérateur param, param, param ....

Mais il y a plus amusant:

En 2002, j’ai utilisé CSound - en temps réel ! - et j’ai trouvé un son intéressant bien que le programme construisant le son me parut bien simple. J’ai enregistré les sons et je m’en suis servi. Mais il fut impossible de reproduire ces sons sur un ordinateur plus rapide. Les résultats sonores étaient conformes à ce qu’on pouvait attendre au vu des programme (à l’époque on séparait les fichiers construisant les sons et les fichiers décrivant la chronologie).

Ce qui faisait l’intérêt des sons était du à l’impossibilité de l’ordinateur à construire les sons dans le temps imparti. Ceux-ci étaient donc en permanence entrecoupés de micro-silences qui étaient à l’origine de craquements, artefacts intéressants mais involontaires. D’où ma méfiance envers toute cette idéologie du temps réel en général et Csound en particulier.

Le défi

C’est pourquoi je lance le défi:

  • réécrire et repenser en un langage multiforme comme Python (et vraisemblablement aussi Ruby) les fonctions en Scheme, Lisp, Guile;
  • comparer la lisibilité des différentes écritures
  • comparer la facilité de maintenance et de réemploi.

On trouvera sans doute que les Lisps sont plus astucieuses et prennent un peu moins de place, mais qu’on a tendance à les utiliser telles quelles sans intervenir sur le code. Ce qui conduit fatalement à une sclérose.

Tandis que les modules en Python sont facilement réutilisables et re-modelables ou re-modulables. Elles invitent à aller plus loin.