Accueil du [Site] > Articles > Découvertes > Faire de la musique avec des algorithmes

Faire de la musique avec des algorithmes

Traduction du dossier spécial consacré à la composition algorithmique.

jeudi 5 juin 2008, par Valentin.

Toutes les versions de cet article : [English] [français]

Comme vous le savez peut-être, je publie sur ce site le LilyPond Report, une revue hebdomadaire consacrée au monde de LilyPond. Ceci est la traduction du dernier numéro spécial, entièrement consacré à la composition algorithmique.

Bonjour et bienvenue pour ce dixième numéro du LilyPond Report !

Ce numéro est entièrement consacré à la Composition Algorithmique ; il regroupe des informations issues d’articles sur Internet, d’ouvrages divers, ainsi que de rencontres avec quelques membres de la communauté LilyPond. J’aimerais à ce titre remercier particulièrement Torsten Anders, Trevor Bača, Jaime Oliver, José Henrique Padovani et Andrea Valle, pour leur aide et leur connaissance du sujet. Comme toujours, vous pouvez réagir à cet article en laissant des commentaires en bas de cette page.

Attention, tous les liens (y compris vers des articles Wikipédia) sont en anglais. Avec un peu de chance, vous pourrez trouver quelques traductions assez facilement ; pour le reste, c’est tout simplement qu’il n’y en a pas.

 L’éditorial de la semaine

Bonjour,
depuis son lancement, le LilyPond Report présente chaque semaine des projets liés à LilyPond. Mais cette semaine, nous allons tenter d’envisager un point de vue moins centré sur LilyPond, et voir au contraire à quel point notre logiciel préféré s’intègre parmi les autres applications musicales.

C’est pourquoi ce numéro sera entièrement consacré aux langages de musique algorithmique. Il est construit pour une large part sur des contributions de Torsten, José, Jaime, Andrea et Trevor, ainsi que de nombreux articles, sites, etc. Ce qui n’était au départ prévu que pour être une chronique s’est transformé, étant donnée la complexité du sujet, en ce numéro colossal.

Pour en faciliter la lecture, il est découpé en passages plus digestes, que vous pourrez lire un par un ou survoler. Mais souvenez-vous bien que cette introduction informelle est écrite par un non-spécialiste ; mon seul but est de vous faire partager mes découvertes, de façon quelque peu désordonnée. Si le sujet vous intéresse véritablement, il faudra vous armer de courage, et aller lire en anglais quelques-uns des liens que j’ai rassemblés.

Ici commence le récit de mon voyage dans le monde étrange de la musique générée par ordinateur.

 Quand les ordinateurs écrivent de la musique...

Premier jour.— La musique algorithmique dans la communauté LilyPond.

Dernièrement, je me suis rendu compte que beaucoup de gens s’employaient à interfacer LilyPond avec divers langages expérimentaux de représentation de la musique :

  • Bernardo Barros essaye de traduire la sortie du logiciel SuperCollider en partitions LilyPond,
  • Karim Haddad vise un but équivalent avec OpenMusic,
  • Jaime Oliver travaille à exporter les données de Pure Data,
  • José Padovani traduit de la musique de Common Music vers LilyPond,
  • David Psenicka a développé Fomus, qui exporte du code LilyPond, ce qui permet ainsi de traduire des langages non libres tels que PWGL,
  • Graham Percival se sert du programme d’analyse sonore Marsyas pour produire du code LilyPond,
  • Torsten Anders a développé son propre système de composition par contraintes, Strasheela,
  • Andrea Valle a développé un système algorithmique complexe qui intègre (dans des modules Python ?) LilyPond, SuperCollider, TeX et autres,
  • Víctor Adán a écrit un kit de modules Python, baptisé Cuepatlahto, pour créer des partitions LilyPond dans une démarche conceptuelle,
  • Trevor Bača avait un projet similaire, dénommé Lascaux ; ces deux projets ont été fusionnés au sein du projet Abjad, en plein développement.

Une liste fort impressionnante — et pourtant il se peut fort que j’en oublie. Quoi qu’il en soit, je me devais de mener l’enquête.

 Cette chose étrange qu’est la composition...

Deuxième jour.— Composition automatisée et Composition aidée par ordinateur

Qu’est-ce que cette étrange chose que l’on nomme Composition Algorithmique ?

Si je comprends bien, c’est lorsque l’on crée de la musique au moyen d’une suite d’opérations mathématiques.

Aujourd’hui Trevor Bača m’a fait remarquer quelque chose à quoi je n’avais jamais pensé : La composition « Algorithmique » n’implique pas nécessairement de se servir d’ordinateurs : la musique écrite il y a des siècles pouvait être tout à fait algorithmique : d’ailleurs il est fréquent de voir, dans les articles ou livres sur le sujet, des références au jeu de dés de Mozart, aux transformations des séries de douze sons, ou même, en France, aux isorythmes de Guillaume de Machaut.

Quand j’y réfléchis, je me rends compte que de fait, les mathématiques sont une part essentielle de toutes les musiques, et en particulier la musique occidentale des cinq derniers siècles, qui a vu cette relation se renforcer — à mesure, peut-être, que la notation musicale se faisait plus précise ? L’art de la polyphonie, du contrepoint à la fugue et au sérialisme, repose sur des principes mathématiques. C’est même encore plus flagrant dans les constructions rythmiques : même la musique techno la plus lamentable est, en gros, faite de 4^n mesures.

J’ai aussi lu un devoir datant de 2003, écrit par Torsten Anders, qui m’a fait comprendre la distinction entre composition automatisée et composition assistée par ordinateur :

  • au contraire, la Composition assistée par ordinateur reste un geste artistique. Je me souviens que Trevor a essayé d’expliquer la même idée : Lorsque des graphistes s’asseyent à leur poste et lancent Photoshop, dit-on qu’ils font du « dessin algorithmique » ou du « bidouillage de photos algorithmique » ? Réfléchis-y un instant ; cela t’aidera à comprendre de quelle façon la composition peut être assistée par ordinateur sans pour autant être totalement algorithmique.

Vu ?

Vu.

 Apprendre la musique aux ordinateurs ?

Troisième jour.— Petite histoire sommaire.

Miller Puckette

Aujourd’hui, grâce à José, j’ai découvert quelqu’un d’important : Miller Puckette. Il faut que vous montre son portrait officiel ; il semble ce type soit l’auteur d’un des programmes les plus importants pour la musique contemporaine.

J’ai commencé à lire son livre Théorie et technique de la musique électronique. Au début, il déclare que « Les techniques électroniques

  • d’enregistrement,
  • de synthèse,
  • de traitement et
  • d’analyse des sons musicaux [...] ont pris leur forme moderne dans les années 1948-1952, mais leurs tenants et aboutissants techniques et artistiques ont connu plusieurs révolutions depuis lors ».

Il est intéressant de constater que pour lui ces quatre disciplines partagent une base historique commune (qui correspond d’ailleurs, en gros, à l’avènement de l’informatique moderne).

A 1956 advertisement

Et de fait, les premiers pas de la composition algorithmique semblent avoir été constitués par l’analyse statistique de musiques existantes. Je découvre à l’instant une réclame de 1956, glorieusement intitulée Une machine qui compose de la musique :

Puisque le fonctionnement de l’esprit humain échappe à l’analyse, l’idée qu’une machine puisse composer de la musique pourrait sembler absurde au premier abord. Pourtant, en combinant l’analyse statistique et la théorie de l’information, nous sommes parvenus à construire une telle machine.

Cette première approche est très clairement ce que Torsten nomme composition automatisée. D’après ce que je vois, elle émergea en même temps que l’utopie de l’Intelligence Artificielle1 ; c’était l’époque où les humains voulaient à tout prix que les ordinateurs se mesurent à eux, que ce soit en écrivant de fausses partitions de Bach ou en jouant aux échecs contre eux.

Cette publicité de 1956 mentionne l’emploi des statistiques dans le domaine musical. C’est très intéressant, puisque cette démarche analytique semble avoir constitué la base de la plupart des expérience de composition automatisée depuis lors. Dans un article daté de 1996 sur la Composition musicale en tant que grammaire, John Mc Cormack rapporte que « divers calculs stochastiques ont été employés dans le cadre de compositions musicales. La plupart consiste en deux temps :

  • D’abord, un fragment de musique existant est analysé.
  • Suivant cette analyse, on procède à une re-synthèse au moyen d’une technique stochastique.« Des statistiques et du hasard : voilà en gros tout ce qu’un ordinateur peut faire pour se déguiser en compositeur »intelligent »2. Pour citer à nouveau McCormack, par exemple, « un outil répandu pour la composition algorithmique est l’emploi de chaînes de Markov [...] La plupart des essais accomplis suivant cette méthode demandent d’abord d’analyser de la musique existante. »

Je note qu’aucune des personnes que j’ai pu interviewer jusqu’ici n’a une seule fois employé le mot d’« intelligence ». On dirait que les mentalités ont changé ces 15 dernières années ; un article de Bruce L. Jacob, écrit au début des années 90, montre bien ce glissement progressif : il évoque l’ordinateur autant comme une intelligence et comme un outil :

La question qu’est-ce que la composition algorithmique est analogue à la question qu’est-ce que l’intelligence artificielle. Les deux sont ardemment débattues. Aucune n’a de réponse facile. Chacune pose des questions fondamentales sur la paternité des idées.

[...] La composition algorithmique est aussi vieille que la composition tout court. On la voit souvent comme un moyen de tricher, une échappatoire pour le compositeur en mal d’inspiration. Mais on peut aussi y voir un outil compositionnel qui permet simplement au compositeur de travailler plus vite.

Un outil.

En d’autres termes, ne nous acharnons pas à apprendre à l’ordinateur à écrire de la musique par lui-même, mais apprenons-lui à écrire ce que nous voulons qu’il écrive. Ni plus, ni moins.

 Chaos und Ordnung...

Quatrième jour.— Hasard et créativité. Générer des notes avec LilyPond.

Franchement, je suis perdu.

Le hasard. Est-ce là le vrai nom de l’« inspiration » ?

Je me souviens du jeu de dés de Mozart. Les ordinateurs savent très bien générer des nombres (apparemment) aléatoires. Cela les rend-il capables de composer également ?

Aujourd’hui je découvre ce type, cet allemand qui s’appelle Karlheinz Essl. J’ai essayé de lire sa thèse en Allemand, et une formule m’a frappé : « die labyrinthische Dialektik von Chaos und Ordnung » (la dialectique labyrinthique du chaos et de l’ordre).

Si je comprends bien, le chaos « pur » (s’il existe où que ce soit) ne pourrait être qualifié d’art : le compositeur doit lui donner une certaine forme, un certain ordre. La création artistique est, justement, ce délicat équilibre entre le hasard et les règles.

De quelque façon que ce soit, il faut dire à l’ordinateur ce qu’il doit faire, et comment il doit le faire. Tout le rôle d’un logiciel de composition est précisément de permettre à son utilisateur (le compositeur) de définir de telles règles facilement.

Ceci implique, un moment ou un autre, que la façon dont le logiciel a été conçu peut influencer la façon dont on va composer. D’après Miller Puckette, le « design » d’un logiciel ne peut qu’influencer le résultat sonore de la musique créée par ordinateur, et pourtant en tant qu’auteurs de logiciels nous devons tout faire pour ne pas projeter nos propres idées musicales dans notre programme.

Au fait, LilyPond lui-même peut écrire de la musique : regardez donc ce snippet, « Générer des notes au hasard ».

Le code demande à Lily

  • de produire uniquement une seule voix (make-music 'NoteEvent)
  • dont la valeur rythmique est invariable (ly:make-duration 2 0 1 1, autrement dit des noires)
  • pas au-dessus du sol aigu ((quotient idx 7))
  • choisies parmi toutes les notes de la gamme ((remainder idx 7))
  • sans aucune altération (0)
  • et de s’arrêter après 24 notes.
GNU Solfege

Un exemple similaire nous est fourni par le logiciel GNU Solfege, créé en 1999 par un LilyPondeur suédois. Solfege est écrit en Python, et comprend plus de 400 règles pré-définies, et 100 modules prêts à l’emploi, pour générer au hasard des gammes, des arpèges, des progressions d’accords... Rien que LilyPond ne pourrait faire ; mais d’une façon ici bien plus simple.

A twelve-notes serie in GNU Solfege

Cependant, Solfege aussi bien que LilyPond ne conviennent qu’à des règles de composition relativement simples. Comme l’a remarqué Jaime, « Je pense qu’une chose pour laquelle LilyPond n’est pas fait est d’accomplir des opérations algorithmiques sur du matériau musical, à part les opérations habituelles de transposition, de transformation rythmique, etc.

La plupart des environnements de programmation sont parfaits pour cela, car ils utilisent des représentations chiffrées. D’où la nécessité de passer d’une représentation à une autre. Je crois que les utilisateurs de LilyPond qui s’intéressent aux calculs algorithmiques auraient besoin de pouvoir créer des nombres, et de les convertir en code LilyPond. »

 Lancer la machine et laisser faire

Cinquième jour.— Approche esthétique. Rencontre avec Trevor Bača.

Il fallait que j’interroge Trevor.

Trevor Bača

S’il y a une chose que j’ai remarquée en ce qui concerne Trevor Bača (outre le fait que c’est un éminent contributeur et sponsor du projet LilyPond) : il a souvent beaucoup à dire.

Je me souvenais avoir lu un long mail de lui sur la liste de discussion en 2007, et donc je lui ai écrit il y a quelques jours, pour lui demander son opinion sur la composition par algorithmes. Sa réponse commençait ainsi : « Salut Valentin, très bon sujet ! J’ai une tonne de choses à dire là-dessus... probablement trop... » — vous voyez ce que je vous disais ? :-)

Okay Trevor, allez, dis-nous ce que tu penses.

— Ce qui m’intéresse, c’est le modèle de la partition, son « formalisme », pour reprendre le terme de Xenakis. LilyPond offre un modèle incroyable... mais ce modèle ne peut être modifié, transmuté, ou quoi que ce soit qu’un compositeur peut attendre d’un environnement conçu pour la composition. Les fichiers LilyPond servent à entrer des données, mais non à les manipuler.

— Cela rejoint ce que José me disait hier. Donc, tu essayes de me dire qu’il faut des outils spécialement conçus ?

— Oui. Il y a quatre ou cinq ans, Víctor Adán et moi-même avons développé, de façon indépendante, deux systèmes différents en Python, pour nous assurer un contrôle formel sur les partitions musicales. Son projet s’appelait Cuepatlahto, et le mien Lascaux.

— Intéressant, cela me rappelle la façon dont LilyPond a commencé...

— J’ai pris l’avion pour New York pour que Víctor et moi puissions comparer notre code ; et nous avons décidé de réunir nos deux projets. Le résultat est Abjad, un tout nouveau système qui reprend le meilleur de Lascaux et de Cuepatlahto, en nettoyant et améliorant le modèle.

— D’accord. À ce que je vois, c’est un système en plein développement...

— Oui. En gros, on pourrait dire que c’est une extension de l’interpréteur Python interactif, conçue pour permettre à l’utilisateur de construire des instances de plus en plus volumineuses d’éléments de notation comme des triolets, des portées, sachant que tout cela se formate tout seul en code LilyPond.

On peut le comparer à certains systèmes existant : par exemple, le système athenaCL de Christopher Ariza modèle des évènements dans le temps, et se concentre sur la création d’une liste d’évènements ; Abjad modèle une partition musicale, et se concentre sur la création d’un code LilyPond enchâssé hiérarchiquement.

— Pourquoi cette idée ? Qu’est-ce qu’un tel système permet de faire ?

— Ce qui m’intéresse vraiment, ce n’est pas *quel* outil utilise tel compositeur, mais *ce que* fait le compositeur avec son outil. Dans ma musique, j’essaie d’obtenir des textures massivement composites, et d’élaborer des gestes qui dépendent de tellement de détails qu’ils en deviennent difficiles à régler à la main. J’étudie aussi mon propre matériau musical pour en extraire des séquences pré-formées que je puisse étendre, développer, ou confronter à des idées nouvelles au sein d’une même pièce (ou même dans des pièces futures). Et donc j’utilise des ordinateurs.

Je crois que l’important est que certains trucs sont vraaaaiment trop compliqués à faire soi-même, et que les ordinateurs nous donnent un sacré coup de main. Il est bien plus facile de gérer, par exemple, une palette de 18 types d’attaque différents à la flûte, interagissant et se répondant de façon séquentielle, lorsqu’on a un modèle symbolique dans un coin. Et il est aussi plus facile de reprendre ses propres pièces en se posant des questions comme : « combien y a-t-il de quintolets de triple-croches entre la mesure 31 et 90, où les intervalles consécutifs ne dépassent pas la tierce mineure ? » lorsqu’on a une instance structurant les données de sa propre pièce, que l’on peut modifier ou interroger.

— Hmm. Je vais reposer la question, d’accord : qu’est-ce que cela permet, concrètement ?

— En 1993, j’ai commencé une pièce que j’ai depuis baptisée « Poème récursif » (en Français dans le texte). La pièce d’origine faisait seulement 13 pages, pour 16 percussionnistes jouant un total de 64 mesures plus une. Voici une page de cette version d’origine.

1993 version

Douze ans plus tard, en 2005, j’ai écrit une deuxième « strophe » de ce « Poème ». Les dimensions avaient été étendues à 64 parties, et une longueur de 256 mesures.

2005 version

On peut voir au premier coup d’œil le rôle joué par LilyPond dans la composition : l’esquisse de 1993 a été écrite entièrement à la main, et cela m’a pris des semaines, même après que j’aie déterminé précisément la structure de la pièce. Je me souviens avoir été tenté d’aller bien plus loin à l’époque, mais devoir faire ça à la main était rédhibitoire — cela impliquait des milliers de notes par page.

LilyPond entre en scène. Avec le code comme interface, et LilyPond en sous-main, j’ai pu me dépatouiller dans des dizaines et des dizaines de configurations impliquant toutes sortes de paramètres, d’essai en essai en essai jusqu’à trouver exactement les bons fragments des bonnes structures à manipuler, encadrer, exploser et recombiner pour obtenir ce que je voulais.

— Je commence à comprendre... (enfin je crois).

— En vérité, je me suis toujours senti mal à l’aise avec cette démarche. Qu’exprime-t-on au juste lorsque l’on forge des algorithmes et des séquences ? Rechercher des variations, que ce soit à la main ou à la machine, c’est une chose. Mais je vois comme une ligne rouge qu’on risque de franchir en employant certains types d’algorithmes tellement... je ne sais pas, colossaux... qu’ils peuvent générer des pièces entières, d’aspect monolithique et fermé. Bien sûr, je n’ai rien contre cet aspect monolithique ; mais il faut une certaine forme de magie noire pour pouvoir s’exprimer réellement au travers de cette démarche de « lancer la machine et laisser faire ». Et je crois que cette magie est encore trop noire pour moi.

— « Lancer la machine et laisser faire » ?

— J’ai piqué cette expression à Andrea, c’est comme ça qu’il parle de sa propre démarche. Et je crois même qu’il se présente comme « doté d’une mentalité radicalement lancer-la-machine-et-laisser-faire. » Ce qui montre que certains parmi nous maîtrisent cette forme particulière de magie noire... :-)


Après que ce dossier a été publié en anglais, j’ai reçu un mail de Víctor Adán, qui complétait ce que Trevor avait déclaré :

Je voudrais juste ajouter un commentaire sur la composition algorithmique en générale. Les définitions que je connais s’articulent toujours autour de la *méthode* d’écriture, et suscitent donc des débats sur la validité ou non de telle ou telle méthode : est-ce qu’utiliser de l’aléatoire fait de soi un compositeur algorithmique ? Ou bien affecter des automates cellulaires aux hauteurs de notes ? Ou bien utiliser des gammes de douze notes ? Ou bien des contraintes ?

Pour ma part je crois que la composition algorithmique est, autant qu’un modèle esthétique, une façon d’envisager la composition sous une forme méthodologique. En composition algorithmique ce n’est pas tant la succession particulière des sons ou des notes qui importe, que l’algorithme qui l’engendre ; en d’autres termes, savoir comment une chose est produite est plus important que de savoir quoi. La musique n’est qu’un effet secondaire — ou même une jauge — de l’algorithme, qui est le véritable objet d’art digne d’intérêt.

Merci à Trevor et Victor ; bonne chance pour votre projet commun !


Après cette conversation avec Trevor, je voulais enquêter sur un petit détail. Il avait parlé de Christopher Ariza, un nom qui m’avait déjà été donné par les autres.

J’ai donc ouvert son site web, pensant que j’allais peut-être découvrir un nouveau logiciel de composition que je ne connaissais pas...

Et c’est alors que je suis tombé sur ça.

Cette liste de systèmes de composition.

ouuuuuuh...

Je compte...

118 trucs différents !!!

Oh, non...

 Complètement implémenté !

Sixième jour.— le Common Lisp. Test de Fomus.

Tant de programmes, tant de systèmes, tant de gens...

C’est une des premières choses que Torsten m’avait dites, il y a quelques jours : « Il existe un nombre impressionnant de systèmes de composition. » Jamais je ne me serais douté à quel point cette déclaration était vraie...

Cependant, Torsten m’a aussi fourni un bon angle d’approche : « Différent langages de programmation sont utilisés, mais le Common Lisp est un peu la lingua franca de la composition algorithmique (pour des raisons historiques et culturelles, j’imagine). »

Effectivement. Il y a quelques semaines, le LilyPond Report a déjà évoqué Igor Engraver, un logiciel de notation musicale écrit en Common Lisp ; il y a aussi un certain nombre de langages spéciaux pour la musique qui ont été fondés sur le Common Lisp :

  • Fomus, qui traduit des données algorithmiques compositionnelles vers différents formats de notation (Lilypond, MusicXML...)
  • Common Music (et son ancêtre Pla, écrit par Schottstaedt), un système de composition,
  • Compo, un autre système de composition,
  • Patchwork, un système de composition et de programmation visuel (l’utilisateur crée des évènements dans des boîtes qu’il relie ensuite entre elles) — et ses deux dérivés :
  • PWGL, qui n’est pas libre3.

Difficile de ne pas s’y perdre, n’est-ce pas ?

En quoi le Common Lisp est si apprécié ? D’après Torsten, «  le Common Lisp est un compromis, qui rassemble de nombreux avantages de plusieurs dialectes issus du vieux Lisp ; c’est donc un langage *colossal* »4.

Il y a mieux : le Lisp est un langage de haut niveau5, et multi-paradigme6

À titre d’exemple, José Padovani m’a expliqué ce que le Common Lisp (et notamment le Common Lisp Music) lui permettait de faire :

José Padovani

Je génère des bouts de code qui écrivent du code LilyPond. Puis je lance LilyPond pour voir le résultat de mes « expériences ». Ces fragments de code ne sont pas organisés en bibliothèques comme Fomus : je ne suis pas un programmeur mais un compositeur.

Dans une de mes pièces, j’utilise du code Lisp pour mesurer le rythme d’un texte parlé. Ce code est très particulier, pour s’adapter à mes préférences : je veux que les mesures commencent là où se trouvent des syllabes accentuées, etc.

Dans un autre projet, j’ai écrit un code Lisp qui crée certaines « textures » à partir d’algorithmes génétiques, et qui écrit le résultat sous forme d’une pièce pour 18 instruments, avec quelques règles rythmiques. Ce qui est sympa, c’est que j’avais utilisé ces fonctions auparavant pour générer des grains sénoïdes ; comme j’aimais le résultat, j’ai décidé de réutiliser ça pour un orchestre à cordes.

Eh bien, tout cela m’a donné envie de mettre mes mains dans le cambouis. J’ai pris la liste ci-dessus, et j’ai décidé de tester le premier de ces programmes : Fomus.

— Test de Fomus

Fomus a été développé par un ex-LilyPondeur nommé David Psenicka ; comme je l’ai dit, il est écrit en Common Lisp (mais José m’a informé que son auteur est en train de le recoder en C++). Son nom signifie « MUSique FOrmelle », et d’après sa description « Ce logiciel a pour but de faciliter la conversion de données algorithmiques brutes en notation musicale lisible, un processus qui peut s’avérer très frustrant. FOMUS s’emploie à faire disparaître cette frustration en devinant de façon raisonnablement intelligente les notes, les durées, et en organisant ces informations dans des voix et des portées. » Il supporte différents formats en export :

  • LilyPond
  • MusicXML
  • Common Music Notation
  • MIDI

Donc beaucoup d’exports possibles. Ce choix est ce que Torsten nomme une « représentation musicale de format neutre »7

Fomus se présente sous la forme d’une archive compressée. après décompression, on a le choix entre charger Fomus dans un interpréteur Common Lisp, au moyen de la commande
(load "load.lisp") and then (use-package :fm), ou
de l’installer comme logiciel à part entière, grâce au petit script ./install.sh (contrairement à LilyPond, il n’est pas fourni avec son propre interpréteur, aussi faut-il installer, par exemple, Gnu Common Lisp auparavant).

En fait, je ne suis pas parvenu à le faire fonctionner (apparemment il y avait un bug dans le code des altérations automatiques). Cependant, j’ai trouvé des bouts de code sympas dans la documentation :

Fomus n’est encore que très peu documenté. Mais il paraît très intéressant, et sa syntaxe est d’aspect si familier que j’en viens à souhaiter qu’on puisse l’implémenter entièrement dans le langage Scheme, et par ce biais en faire une surcouche très cool pour LilyPond. Cela en ferait une application plus facile d’accès, et entièrement multi-plateforme.

De plus, il semble ne supporter que Lilypond 2.4. Ce projet est vraiment sympathique, qui a moins besoin d’idées intéressantes que de ressources pour les implémenter.8.

 Des sons et des notes

Septième jour.— Rencontre avec Andrea Valle et ses systèmes « fluides ». Électroacoustique.

Aujourd’hui j’ai reçu un mail d’Andrea Valle, de l’université de Turin.

En fait, mon approche est très éclectique ; parfois j’utilise du Python, parfois SuperCollider, pour « coller » les trucs ensemble ; parfois le résultat est au format LilyPond, parfois c’est de la notation graphique.

Donc, l’idée d’un système général me laisse plutôt sceptique, comme je change de solution d’une pièce à l’autre.

Andrea Valle

En jetant un coup d’oeil sur la page MySpace et Youtube page d’Andrea, j’ai compris que des langages musicaux très différents l’intéressent, y compris des systèmes acousmatiques.

Je l’avais presque oublié, mais beaucoup (la plupart même) de musiques contemporaines de ces cinquante dernières années sont en fait des musiques électroacoustiques, faites de sons plutôt que de notes9. « Beaucoup de systèmes de composition algorithmique sont aussi des systèmes de synthèse sonore », comme me l’a fait réaliser Torsten.

Dans un article qui sera bientôt publié à Nime2008, Andrea émet quelques suppositions intéressantes sur la relation entre l’électroacoustique et la musique algorithmique :

La composition algorithmique a été promue et généralisée dès les années 50. Mais un changement de perspective s’est produit, en gros, entre les années 60 et aujourd’hui.

Les premières approches de la composition algorithmique étaient motivées par la notation instrumentale. Mais l’approche purement algorithmique, dans laquelle la compsition entière est gouvernée par un formalisme strict, n’est plus tellement utilisée en tant que telle, et a migré du domaine instrumental vers l’électroacoustique.

Et pourquoi cela ?

En fait, si l’on considère la composition comme un processus aboutissant à un résultat, dans le domaine électroacoustique, synthétiser des sons est une tâche très facile, tandis que dans le domaine instrumental, générer une notation musicale demeure une tâche très difficile.

Ce problème de la notation a empêché les pratiques authentiquement algorithmiques de se répandre dans la composition instrumentale. Une telle approche, dans laquelle la composition devient un flux algorithmique, de la première idée jusqu’à la partition définitive, pourrait être définie comme « Composition Algorithmique Intégrée »

Vous l’aurez deviné, cette Composition Intégrée est ce qui intéresse Andrea — souvenez-vous, « lancer la machine et laisser faire ».

Comment s’y prend-il ?

Au lieu de partir d’un environnement rigide où l’on insère des modules...

(Ce que l’on fait avec le Common Lisp, comme nous l’avons vu.)

[...] Il est possible de partir d’une quantité indéfinie de modules disponibles, à intégrer lorsque nécessaire dans un environnement ouvert. Un tel environnement est fluide, parce qu’il sert de « colle » pour attacher ensemble des modules différents.

En d’autres termes, il ne s’agit plus d’implémenter des modules dans un programme unique, mais d’écrire un « meta-programme » (en anglais, un « wrapper ») autour de plusieurs programmes complètement différents.

A Python wrapper for graphical notation

Cette méthode peut servir à gérer des notes générées aléatoirement (démarche stochastique) ou à interagir en temps réel avec certains événements, par exemple une entrée audio :

Dans un projet de composition qui impliquait l’extraction de paramètres à partir de signaux audio, j’utilise comme point de départ l’enregistrement d’un extrait de Antigone de Sophocle, lu par un philologue afin de respecter autant que possible la prononciation restituée du grec ancien. Trois voix chantent des mélodies générées à partir de l’analyse du fichier audio d’origine, en particulier en fonction des fréquences fondamentales et des deux premiers formants.

Le logiciel Praat a été choisi pour gérer l’analyse. SuperCollider a été choisi à la fois comme « colle » pour le système et comme module audio : le langage de SuperCollider est riche de structures, très expressif, fournit une interface pour le système d’exploitation, permet la manipulation de chaînes ; enfin en tant que serveur audio, il fournit un traitement du son de haute qualité.

Et la sortie en tant que partition ? Je vous donne un indice : elle s’appelle Pond...

Cliquez ici pour écouter un extrait.

Je ne sais pas vraiment si la musique électroacoustique est plus « purement » algorithmique que la musique faite de notes et de partitions. Je n’ai pas étudié la question comme l’a fait Andrea, mais il me semble que beaucoup de musiques électroacoustiques, à un certain point, reposent sur des choix arbitraires du compositeur, autant que dans n’importe quelle musique (la structure de la pièce, les gestes musicaux, etc).

Ce qui est certain, en revanche, est que la plupart des institutions dédiées à la musique contemporaine dans le monde se consacrent autant au son en lui-même (traitement, synthèse) qu’aux algorithmes et à la programmation. Parmi ces institutions, voici quelques-unes parmi les plus célèbres :

  • l’IRCAM à Paris, où a travaillé Miller Puckette, et où officie manifestement le LilyPondeur Karim Haddad,
  • le CCRMA à l’université de Stanford aux États Unis, et
  • le ICCMR à Plymouth en Angleterre, où travaille Torsten Anders.

 Le modèle Max

Huitième jour.— Miller Puckette, Max Mathews. Test de PureData.

Vous vous souvenez du dénommé Miller Puckette ? Il y a quelques jours, José m’a conseillé de lire un article de lui, intitulé « Max à dix-sept ans ». Qui c’est, Max ? En fait c’est un logiciel qu’il a développé lorsqu’il travaillait à l’IRCAM dans les années 80. Ce programme fur nommé ainsi en hommage à un programmeur très important du XXe siècle : Max Mathews.

Retour dans les années 50 — vous vous souvenez, quand les gens voulaient construire des machines qui écriraient comme Bach ? Eh bien d’autres personnes, à l’époque, commencèrent à voir en l’ordinateur non un cerveau, non un outil, mais... un instrument de musique.

Dès 1949, le CSIRAC (le tout premier ordinateur d’Australie) parvint à jouer un son numérique. Cependant c’est aux États-Unis que Max Mathews développa le langage de programmation MUSIC, qui est selon José le « père » de tous les programmes audio modernes (par exemple le logiciel libre très connu CSound, créé par Barry Vercoe, un élève de Mathews).

Dans les années 80, Miller Puckette (à son tour un élève de Vercoe), à l’IRCAM, imagina un nouveau modèle de programmes, conçus pour des « représentations musicales en temps réel ».

Comment définiriez-vous un instrument de musique ? Un piano est-il pour vous constitué de 88 touches et de trois pédales ? Eh bien pour Puckette, « dans un environnement multi-tâches, on pourrait décrire le piano comme 91 tâches, une pour chaque touche et chaque pédale. L’exécutant — le pianiste — choisit dans quel ordre il va lancer ces 91 tâches, et combien de fois il va les lancer. ».

Commencez-vous à comprendre ? Max sert principalement à définir des événements, puis à les déclencher quand on est sur scène. C’est une application « en temps réel », qui peut aussi bien gérer des échantillons sonores pré-enregistrés que des notes, comme nous le verrons plus loin.

Beaucoup de logiciels musicaux sont orientés vers un emploi en temps réel. Cela inclut SuperCollider, que nous avons déjà mentionné dans le LilyPond Report, et ChucK. Mais pour autant que je puisse juger, ceux-ci sont tous deux conçus pour le traitement et la synthèse du son que pour produire des notes.

— Test de PureData

Donc me voilà, décidé à installer et tester Pure Data (pd), qui est l’implémentation Libre que Miller a faite de son logiciel Max.

Comme j’étais sous Windows à ce moment-là, j’ai pu remarquer les capacités multi-plateformes de PureData (tandis que le Max d’origine était seulement pour Mac — sans jeu de mot). À ce que je vois, c’est dû à la librairie graphique Tk.

Lorsqu’on lance pd, ou que l’on crée un nouveau projet, on se retrouve face à une fenêtre toute blanche. D’après Puckette, ce choix est délibéré :

Au lancement de Max, l’utilisateur ne voit rien d’autre qu’une page vierge : pas de portées, pas d’armure ni de chiffre de mesure, pas même de notion de « note », et certainement aucune « voix » ou « séquence » instrumentale. Cette page vierge même est chargée d’un poids culturel et stylistique à au moins un titre : toute l’idée de faire intervenir du papier dans la démarche de production de musique fut une innovation de la musique savante occidentale, et bien d’autres musiques n’en ont pas du tout l’usage.

« So say we all... » (subtile allusion)

Bon bon, essayons donc de mettre quelque chose sur cette page blanche :

My first attempt at pd
(mon premier essai avec pure data)

Comme vous le voyez, différents objets sont disponibles, mais il est surtout question de boîtes. Une boîte peut contenir un événement musical, ou bien déclencher un autre événement, ou encore les deux à la fois. En fait, on construit soi-même sa propre interface, comme on veut.

Là encore je n’ai pas pu aller plus loin. Voyons si YouTube peut le faire pour moi :

Regardez aussi cette vidéo, qui élargit le même principe.

L’ordinateur comme instrument de musique. C’est... Eh bien, c’est en fait sympa, si l’on en croit Miller Puckette :

La science informatique n’a jamais trouvé d’unité de mesure pour déterminer si un programme d’ordinateur est sympa à utiliser ou pas.

[...] On dit « jouer » du violon, pas « élaborer » du violon. Si le fait de se servir d’un logiciel est aussi agréable que de travailler dans une banque ou dans un fast-food, les musiciens ne voudront jamais (et ne devraient pas avoir à) s’en servir.

[...] L’ordinateur, idéalement, devrait tomber sous les doigts d’un musicien comme un instrument, demandant seulement à être accordé et à être joué.

 Le compositeur en tant qu’usager de logiciels

Neuvième jour.— La Lexikon Sonate. Temps réel et temps absolu. Interfaces graphiques et textuelles.

Les vidéos d’hier montraient des échantillons sonores issus d’enregistrements réels. Cependant PureData-Max peut aussi prendre en charge le format MIDI, et de ce fait générer des notes de musique par lui-même — ce qui nous ramène à la composition par algorithmes.

Pour citer Miller Puckette, qui a l’air assez navré par le MIDI (mais qui ne l’est pas) :

À cause des limitations techniques, en 1987 (on pouvait avoir une interface graphique ou un synthétiseur de sons mais pas les deux en même temps dans la même mémoire), Max est devenu un « programme MIDI ». Cependant, rien fondamentalement n’était dérivé du MIDI dans Max : c’était une interface d’entrée/sortie, et rien de plus.

— La Lexikon Sonate

L’autre jour je vous ai parlé de Karlheinz Essl. Il fallait absolument que je vous montre une de ses compositions : la Lexicon Sonate, composée et interprétée au moyen de Max.

Je suis très impressionné par l’expressivité de cette oeuvre. On entend (on ressent) dinstinctement les progressions dramatiques, les gestes musicaux, la tension etc.

Le rendu sonore, si je comprends bien, est entièrement en MIDI, bien que le résultat ne soit pas si mal en fait. Rien n’est ici pré-enregistré, toutes les notes sont générées à la volée, et démontrent clairement ce que peuvent être des gestes musicaux générés en temps réel. Regardez aussi la page web où l’auteur explique tout : par exemple la manière dont il dénomme ses événements musicaux est partculièrement intéressante. Esprit, Joie, Nuages, ...

— Temps réel

Ce pouvoir de créer des événments pendant même l’exécution, comme l’on ferait en improvisant sur un instrument réel, est ce que l’on appelle communément le traitement en « temps réel ».

Qu’apporte le temps réel, en termes de facilité d’utilisation ?

Jaime Oliver

Jaime — À vrai dire, pouvoir changer les paramètres pendant que j’écoute le résultat fait toute la différence.

Le fait qu’il s’agit d’une application « temps réel » ne l’empêche pas d’être un environnement de programmation très complet et capable d’enregistrer des informations représentées de différentes manières. Être en temps réel n’implique pas que je ne peux pas produire des données pouvant ensuite être utilisées quand je suis « déconnecté », ou bien utiliser, en temps réel, des données « déconnectées ».

En tant que compositeur/musicien informatique, ce qui m’intéresse personnellement est de pouvoir passer d’une représentation à une autre ; bien sûr l’une d’entre elles est la partition musicale, en tant que moyen de communiquer avec d’autres musiciens, particulièrement des interprètes dotés d’instruments occidentaux traditionnels. Cela implique d’utiliser des techniques algorithmiques pour générer du matériau mélodique, harmonique ou rythmique, et de le traduire ensuite en code LilyPond.

José — Même s’il est puissant pour concevoir des systèmes temps-réel, PD ne convient pas au traitement en temps non-réel des partitions ou des structures symboliques de la tradition musicale occidentale. Je veux dire : une « croche » ou une « portée » ne représente rien pour PD.

J’utilise beaucoup PD, mais seulement pour du temps réel : cela convient aux expériences sur le son, ou pour les projets musicaux interactifs (impliquant par exemple un instrument et un système électronique).

— Mettez-vous d’accord : peut-on, oui ou non, utiliser un système temps réel pour produire des partitions ?

Jaime — Pd permet aussi bien de la synthèse sonore que de créer des partitions : bien qu’il n’ait pas de format de notation en tant que tel, on peut représenter une « partition » de bien des façons, la plus simple étant des listes, des tableaux ou des fichiers de texte. J’ai vu les tentatives de Miller pour faire des partitions et elle n’arrivent pas à la semelle de LilyPond ; ses tentatives sont juste un affichage temporaire.

C’est pourquoi je suis en train de développer un programme qui prend des paires hauteur-durée, et les convertit en une partition LilyPond.

Torsten — Comme José l’a dit, PD n’a pas été conçu à l’origine pour créer des partitions écrites, cependant beaucoup d’autres systèmes le sont, et la plupart de ceux-là exportent du format LilyPond.

Au passage, il est bien plus facile, par ce biais, de créer des partitions LilyPond que, disons, des fichiers Finale — le format texte de Lilypond est très bien documenté, et relativement facile à créer de façon automatisée.

Un autre aspect que j’aime en créant des fichiers LilyPond pour de la musique algorithmique, c’est la possibilité d’annoter automatiquement la partition avec des informations analytiques, créées en même temps que le résultat de l’algorithme proprement dit.

— Y a-t-il une différence forte, fondamentale, dans la conception d’un logiciel musical en temps réel par rapport aux autres logiciels ?

Torsten — Y a-t-il une différence forte entre l’improvisation et la composition ?

Certains systèmes se concentrent sur la synthèse sonore, d’autres sur l’interactivité, d’autres sur la représentation écrite de la musique, etc. Certains se consacrent à de multiples objectifs, mais en tout cas ces objectifs sont toujours différents.

José — Ces dernières années, ces deux sortes de programmes se rapprochent. PWGL, par exemple, sait traiter et synthétiser du son en temps réel, mais a aussi son propre format de notation.

Marcos Alessi Bittencourt est parvenu à créer des boîtes dans PureData, contenant des partitions, au moyen d’une traduction en C du langage Common Music Notation.

Ce serait aussi très cool de pouvoir représenter visuellement, dans PureData, des fonctions écrites en Common Lisp (par exemple en utilisant le protocole Open Sound Control), comme le font PatchWork et ses dérivés. Il y a déjà une sorte d’interface Lisp pour Max, et maintenant une implémentation Java aussi...

— Interfaces

— José, vous parliez des représentations visuelles ; il est vrai qu’il y a une différence fondamentale entre les programmes dont on se sert en tapant du texte, comme LilyPond ou Fomus, et les programmes graphiques tels que Pure Data ou OpenMusic... Ça ne constitue pas un plus, d’avoir un retour visuel ?

José — Je m’intéresse aux visualisations de toutes sortes. Par exemple, j’ai utilisé des fonctions markoviennes de Common Music pour créer de la poésie assistée par ordinateur, d’après des poèmes du célèbre poète brésilien Carlos Drummond de Andrade, et j’ai généré des visualisations des textes parlés avec Processing, un langage Java pour les arts visuels (qui contient d’ailleurs des bibliothèques de synthèse sonore, et qui peut être lié à PD, SuperCollider ou Max avec le protocole Open Sound Control).

Trevor — Je dépends énormément de la notation musicale sous forme de partition quand je travaille, et je sais pertinemment que je n’aurais jamais pu écrire mes dernières pièces sans avoir le code d’un côté, la partition de l’autre — ce qui fait de LilyPond une nécessité.

Torsten — Le but global de différents systèmes est toujours le même : fournir une boîte à outils bien remplie pour définir des modèles théoriques de musique algorithmique.

Mais, là ou certains mettent l’accent sur l’accessibilité de ces outils à des non-programmeurs, les programmes impliquant du code visent un autre public : les utilisateurs qui, soit ont un peu d’expérience en matière de programmation, soit veulent prendre le temps d’apprendre à coder. (Ils n’ont cependant pas besoin d’être programmeurs professionnels : je suis moi-même musicien de profession.)

Je comprends tout à fait que la programmation visuelle soit plus attrayante pour beaucoup d’utilisateurs. Mais pour mes propres besoins, un langage de programmation visuel n’est « pas de taille » — les morceaux de musique compliqués deviennent un plat de spaghetti :)

 Musiques de la cité d’Émeraude

Day ten.— Torsten Anders. Des règles, des contraintes. Test de Strasheela.

Mon voyage touchait à sa fin, mais je ne pouvais pas partir sans rendre une petite visite à Torsten Anders.

Je vous l’ai déjà dit, Torsten travaille à l’ICCMR à Plymouth en Angleterre. Sur le site de l’ICCMR, il est écrit :

« Nous nous intéressons principalement à la modélisation informatique de la Musique. Nous développons de nouveaux systèmes intelligents, qui seront capable de construire leur propres règles de composition et d’interagir avec les musiciens et les auditeurs d’une façon bien plus sophistiquée que ne le peuvent les programmes d’aujourd’hui. Nous prédisons l’avènement de nouvelles musiques, générées à la volée, et qui demanderont de nouveaux modes de représentation, d’accès et d’interaction. »

Beaucoup de promesses, pas vrai ?

Torsten Anders

Jetez donc un coup d’oeil à la liste des publications de Torsten, qui sont toutes disponibles gratuitement10 J’ai déjà cité son mémoire de 2003 :
Composer de la musique en composant des règles : la composition assistée par ordinateur et son recours à la programmation par contraintes logiques. ;
les citations qui suivent seront extraites de là, ainsi que de sa thèse :
omposer de la musique en composant des règles : conception et utilisation d’un système générique de contraintes musicales.

Comme ces titres le montrent, Torsten s’occupe de « règles » musicales, et de « contraintes » programmées.

En gros, les secondes ne sont autres que l’implémentation des premières. La musique se fonde sur des règles ? Apprenons à l’ordinateur à appliquer ces règles !

Pendant des siècles, les règles de composition ont servi à exprimer la connaissance compositionnelle sous forme d’une théorie de la musique.

L’attitude de la composition assistée par ordinateur par contraintes et très proche de la façon dont les musiciens et les ouvrages musicaux parlent et pensent : les musiciens, par exemple, décrivent souvent tel ou tel style compositionnel comme un ensemble de règles de composition. le concept de composition par contraintes est de ce fait compris intuitivement par de nombreux musiciens.

Beaucoup de musiciens se sentent donc à l’aise avec un modèle informatique fondé sur la notion de règles. Par exemple, de telles approches ont soulevé beaucoup d’intérêt auprès des compositeurs, parce qu’en définissant des règles les compositeurs peuvent formaliser virtuellement tout patrimoine de connaissance compositionnelle, sous forme d’une tâche que l’ordinateur peut accomplir automatiquement.

Qu’est-ce qu’une « règle compositionnelle » au juste ?

Pour un compositeur, il est très naturel de décrire une partition ou un style musical par des règles de composition modulaires.

Une règle restreint certains objets de la partition (par exemple des ensembles de notes) et leur paramètres (par exemple des durées ou des hauteurs). Une règle contrôle souvent des dépendences mutuelles entre plusieurs de ces objects et de ces paramètres.

Les règles de composition décrivent particulièrement bien la musique, parce qu’elles décrivent la nature multi-dimensionnelle de la musique de façon modulaire. Lorsque l’on écoute de la musique, l’on perçoit simultanément des aspects variés tels que le rythme, l’harmonie, la mélodie ou l’instrumentation.

De même, la formalisation d’une tâche aussi complexe que la composition est grandement simplifiée quand cette tâche est présentée de façon modulaire. Quand on décompose la description de cette tache en règles de rythme, règles d’harmonie etc., les différentes dimensions de la musique sont formalisées une par une.

Donc le programmeur se met au service du compositeur pour lui permettre de définir ses propres règles de composition, comme autant de « Problèmes de statisfaction de contraintes ».

En gros, on pourrait voir ce logiciel comme un tamis (ou un crible) qui filtrerait des évènements générés aléatoirement, pour ne retenir que ceux qui satisfont aux contraintes édictées. Certains objets vont être laissés au hasard (ce que l’on nomme des variables inconnues), d’autres vont être contraints.

Le programme ne veut pas affecter le style du compositeur, et de ce fait ce « hasard » doit être le plus générique possible : en d’autres termes, si l’on donne aucune règle au programme, il devrait être capable d’inventer n’importe quelle musique possible — Torsten dirait que son champ de recherche est infini.

Le système de contraintes le plus générique permettrait à son utilisateur d’implémenter n’importe quelle théorie de la musique imaginable. Du point de vue de la présente étude, un tel système serait un système idéal.

L’ensemble des solutions possibles pour ce système (qui est seulement théorique) contiendrait toutes les partitions concevables. L’utilisateur pourrait librement contraindre n’importe quelle variable inconnue pour réduire l’ensemble des solutions possibles comme il le souhaiterait.

Donc il n’est plus question de partir de rien et de fabriquer de la musique, mais au contraire de partir d’une infinité de partitions possibles, et de restreindre ces solutions possibles pour qu’elles correspondent à ce qu’on a en tête.

Ces règles peuvent s’appliquer de différentes façons :

Les compositeurs préfèrent souvent une méthode de travail située quelque part entre la composition à la main et le formalisme déléguant la composition à l’ordinateur.

Par exemple, le compositeur peut déterminer certains aspects de la musique (certaines hauteurs, par exemple) à la main, et contraindre d’autres aspects par des règles. Ou bien le compositeur peut spécifier la structure formelle à la main, et laisser l’ordinateur remplir cette structure en détail.

Des [contraintes déterminantes] peuvent être utilisées de concert avec d’autres règles de composition. [...] Un exemple traditionnel qui recourt à une technique similaire est le début de la quatrième symphonie de Johannes Brahms. Tous les intervalles entre les huit premières hauteurs du thème sont des tierces descendantes (ou des sixtes montantes, ce qui revient au même) — formant ainsi une séquence simple de hauteurs, qui est contrôlée de surcroît par l’harmonie sous-jacente.

Cette approche a déjà été implémentée dans PatchWork et OpenMusic (par le truchement de OMClouds, PWConstraints and Situation). Bien que je ne les connaisse pas (et n’aie pu trouver de documentation accessible), il est temps pour moi de vous présenter le résultat de la recherche menée par Torsten : voici... Strasheela !

Strasheela by Leonid Vladimirsky

— Test de Strasheela

Strasheela est le nom du gentil épouvantail dans la version russe du Magicien de la Cité d’Émeraude. Vu que le logiciel est écrit dans le langage Oz, vous saisirez l’allusion.

Strasheela est un des projets les mieux documentés que j’aie rencontré pendant mon enquête. Non seulement les articles de Torsten sont entièrement accessibles, mais la documentation de Strasheela est très sympa et semble prometteuse — le chef de la documentation de LilyPond, Graham Percival, y a contribué ; serait-ce une coïncidence ?

Launching Strasheela through Emacs

Strasheela nécessite une implémentation du langage Oz pour fonctionner ; la seule disponible est Mozart, facile à utiliser au moyen de l’éditeur GNU Emacs editor. Il semble que l’ensemble soit plus ou moins multi-plateforme, mais je ne l’ai testé que sous GNU/Linux.

J’ai parlé plus tôt de Common Lisp comme d’un langage multi-paradigme ; il en va de même pour Oz, qui à l’origine a cependant été conçu suivant un paradigme très spécial : « la programmation par contraintes concurrente, qui réunit les programmations concurrentes, logiques, et fonctionnelles », raison pour laquelle Torsten a choisi ce langage. Oz/Strasheela est de ce fait la toute première « plateforme spéciale de programmation par contraintes pour la composition musicale. ».

Il y aurait beaucoup à dire, par exemple, sur la façon dont les notes sont aléatoirement générées et filtrées (ce que Torsten nomme « processus de recherche »). Cela demande tellement de ressources informatiques que Strasheela permet à l’utilisateur de définir une « stratégie de recherche » spéciale pour rendre ce processus plus rapide et efficace.

Autre chose que je dois mentionner vite fait : la représentation interne de la musique. Si je comprends bien, elle est de nature double : représentation textuelle définie et précise d’un côté, typologie abstraite des données de l’autre. Quelques exemples.

Voici une mélodie simple, et sa représentation textuelle.

Sur un niveau plus abstrait, voici une déclaration du motif de la cinquième symphonie de Beethoven :

motif (durations : [2, 2, 2, 8] pitchContour : [=,=,-])

Voyons maintenant quelques problèmes de satisfactions de contraintes.

Dans l’exemple suivant, on veut une série dodécaphonique symétrique :

Torsten m’a fourni cet autre example, démontrant une progression d’accords micro-tonaux dans un tempérament égal 31. « Non seulement cela démontre une idée formelle de progression d’accords, mais cela montre aussi comment des informations analytiques peuvent automatiquement être ajoutées à la partition grâce à LilyPond. »

Harmonic progression - 31ET

Regardez le code qui génére tout cela, et lisez éventuellement cette discussion à ce sujet.

Enfin, je dois vraiment vous montrer, en vrac, certaines des fonctions les plus cool que j’ai remarquées dans les exemples de Strasheela :

hasDiatonicPitch

hasUniqueMelodicPeak

isConsonant_lessStrict

isConsonant_strict

palindrome

markovChain

Tout comme Fomus, Strasheela est de format neutre : il peut exporter en MIDI, CSound, LilyPond ; il peut aussi s’interfacer avec Fomus pour produire des fichiers MusicXML.

Je ne peux, bien sûr, résumer toutes ses fonctions ici (d’abord cela impliquerait que j’ai tout compris, ce qui est faux). Mais je dois avouer avoir été séduit par ce logiciel et ses promesses.

Je l’ai installé, mais je ne suis pas parvenu à le faire marcher. Je me suis retrouvé avec un message d’erreur « broken pipe » Operating System Error, à mon grand dam.

Cependant, regardez s’il vous plaît ces exemples sur le site web, et vous tomberez peut-être sous le charme à votre tour :

  • cet exemple implémente la théorie de la musique définie par Fux en 1725 ;
  • Un exemple très impressionnant de Contrepoint qui implique également des paramètres rythmiques ;
  • Un exemple des possibilités de Temps Réel avec Strasheela : interfacé avec SuperCollider, Strasheela peut composer un contrepoint ou un accompagnement, à la volée, sur une mélodie.

Cette dernière fonctionnalité est très impressionnante. J’ai cru voir que Torsten a écrit à ce sujet avec le chercheur/compositeur Eduardo Miranda, qui travaille lui aussi à Plymouth.

Si Strasheela s’avère capable d’exécution en temps réel, cela lui donne un poids très important ; nous l’avons vu, de nombreux compositeurs aiment entendre ou voir instantanément le résultat de leur travail, même s’ils ne se produisent pas sur scène.

Et pour revenir à la facilité d’utilisation : ayant vu combien Torsten croyait en l’utilité des interfaces textuelles, et à son choix d’un langage très spécifique, je ne m’attendais pas à le voir réfléchir à d’autres implémentations possibles... Mais voici ce qu’il déclare pourtant quant au futur de Strasheela :

Porter Strasheela vers un autre langage plus largement utilisé dans la communauté de la composition algorithmique, ou mieux adapté aux programmeurs peu expérimentés, rendrait ce système plus facile d’accès.

Un exemple de langague largement utilisé est le Common Lisp, car il existe un nombre considérable de systèmes de composition fondés sur Lisp. Les langages visuels sont aussi très populaires parmi les musiciens (particulièrement les langages permettant des flux de données, comme Max et ses dérivés).

Il serait intéressant de réfléchir sur la possibilité de faciliter, par une programmation visuelle, l’emploi d’un système de contraintes générique comme Strasheela, d’une façon qui puisse être aussi adaptée à des problèmes de contraintes très complexes.

Si cela arrive un jour, Strasheela pourra certainement jouer un rôle majeur dans la création musicale de demain !

 Conclusion

Voilà, ce numéro spécial (et très long) du LilyPond Report finit ici.

J’aimerais vous laisser sur une citation de... Miller Puckette, who else :

Certains éducateurs, qui voient loin, tentent courageusement d’encourager les élèves à construire leurs propres ordinateurs. J’espère voir un jour une culture internationale d’ordinateurs et de programmes musicaux faits-maison.

[...] Les communautés sont nécessaires pour que le savoir s’étende, particulièrement avec les systèmes d’exploitation non-commerciaux. Mais je peux imaginer un avenir où le savoir-faire informatique (y compris savoir assembler une machine, installer un OS, et lancer des logiciels) se trouvera dans n’importe quel village de deux personnes ou plus dans le monde.

[...] Les gens, presque partout, peuvent ou pourront bientôt mettre la main sur un ordinateur et l’impliquer dans leur pratique musicale [...] cela donnera lieu à un changement de plus en plus audible des musiques du monde.

Cela rejoint certaines de mes convictions : plus que jamais, nous autres citoyens du mone Libre avons le pouvoir de choisir de quoi l’avenir sera fait.

J’espère que ce Lilypond Report vous aura permis de faire autant de découvertes étonnantes que moi-même en le préparant.

À titre d’anecdote, cette série d’entretiens a conduit José, Torsten, Trevor et Andrea à décider de créer une plateforme ouverte dédiée à la composition algorithmique. Quelle sera-t-elle ? un Wiki, un forum, une liste de discussion ? Aucun d’entre eux ne le sais encore, mais soyez sûrs que le LilyPond Report vous tiendra au courant de l’événement !

Ainsi se termine le dixième numéro du LilyPond Report.

À la bonne vôtre,
Valentin Villenave


Dès que ce numéro est paru, j’ai reçu plusieurs commentaires ; j’aimerais juste citer ici celui de Trevor :

Il est clair, à mon sens, qu’il y a un écosystème fascinant (même si clairsemé) de compositeurs qui travaillent avec LilyPond de différentes façons. Mais ce qui a manqué jusqu’ici, c’est quelque reconnaissance publique que ce soit de cet état de fait.

Pour prendre un contre-exemple, lorsque l’on regarde l’OpenMusic disponible à l’IRCAM, on tombe tout de suite sur une communauté très visible et publiée de compositeurs et de projets. Mais tel n’est pas encore le cas pour LilyPond.

Je pense que ton article marque l’amorce d’un tournant, en montrant au public qu’il existe en fait un groupe de compositeurs dévoués à LilyPond et qui en ont fait une part entière de leur démarche créative.


[1Détail intéressant, [David Cope parle à la fois d’« intelligence musicale » et de « créativité artificielle », soit deux expressions manifestement forgées sur le concept d’« intelligence artificielle ». Selon Torsten, Cope a obtenu des résultats particulièrement impressionnants dans ce domaine."

[2Une citation intéressante du compositeur Brian Ferneyhough à ce sujet :

Toute prise de décision comporte (je crois) des éléments de hasard, que l’on peut déterminer de différentes façons. C’est cette détermination, cette contrainte, qui donne une impression d’ordre. Il existe des programmes informatiques qui peuvent vous écrire très rapidement une symphonie à la manière de Mozart ; mais ce dont ils sont parfaitement incapables, c’est de trouver l’étincelle de perversion qui fait qu’une pièce est VRAIMENT mozartienne. Notre vrai guide spirituel, c’est le Démon de la Perversité.

[3Ce point a fait l’objet d’un commentaire de Torsten :

« PWGL est disponible gratuitement, mais n’est pas open-source (son créateur Mikael Laurson a gardé un mauvais souvenir de son précédent langage PatchWork, dont l’IRCAM a pris les sources et en a fait OpenMusic, sans rien lui attribuer). Je ne dirais pas que ce n’est pas libre, même si ça n’est pas open-source. »

Malheureusement il y a une grande différence entre un logiciel gratuit et un logiciel libre ; même si je regrette ce qui est arrivé à Laurson, les licences libres telles que la GPL sont précisément là pour empêcher de tels abus.

[4D’ailleurs, il est intéressant de noter que le Lisp était précisément le langage de l’Intelligence Artificielle...

[5Toujours selon Torsten, Avec ce langage le programmeur travail sur un niveau très haut, alors que les langages de plus bas niveau comme le C ou le C++ exigent de prendre en compte beaucoup de détails soi-même, et de passer beucoup de temps à tout définir — le code en devient bien plus long. Le plus bas niveau étant l’Assembleur, qui n’est plus utilisé aujourd’hui sauf quand on veut une vitesse d’exécution maximum. Les langages comme Java ou C# se situent quelque part entre le C et le Lisp ; la tendance est clairement d’aller vers de langages de plus haut niveau, dont beaucoup ont hérité des concepts du Lisp : le Perl, le Python, le Ruby ou le Groovy.

[6Contrairement, par exemple au Scheme ou au C++ language (both used in LilyPond), qui s’utilisent dans une approche functionelle ou orientée objet, le Common Lisp est un langage véritablement multi-paradigme : en d’autres termes, on peut l’utiliser pour coder à sa propre manière. Pour citer l’article de Torsten, « Les capacités d’expression de la programmation multi-paradigme sont probablement aussi une des raisons pour lesquelles le Common Lisp est souvent employé à la base des systèmes de composition assistée par ordinateur. »

[7Ce qui a conduit à un échange intéressant entre Torsten et Trevor :

Torsten — Ne cibler qu’un seul format (Lilypond) permet de le supporter entièrement et facilement. Opter pour une approche plus générale permet d’en supporter plusieurs plus aisément.

Trevor — Tu as tout à fait raison de dire que pour tout système de « génération automatique de notation », le choix d’une sortie « de format neutre » ou « de format spécifique » est une décision majeure. Et tu as aussi raison de montrer les conséquences que cela implique clairement : un format neutre offre un potentiel d’application plus large, un format spécifique offre un contrôle plus « granulaire ».
Les premières version de mon logiciel exportaient du MIDI et du Csound avant de cibler LilyPond, mais en fait les pièces sur lesquelles j’ai travaillé par la suite m’ont montré que j’avais moins besoin de ces deux formats, et davantage besoin de visualiser la notation (les partitions LilyPond). Donc mon dernier projet constitue un choix radical, de délaisser les formats multiples pour LilyPond exclusivement, juste pour des raisons pratiques.

[8Nous l’avons vu, Fomus supporte beaucoup de formats à l’export. Mais il est intéressant de noter que José autant que Torsten ont avoué n’y voir qu’un « traducteur musical de Lisp vers LilyPond. »

À mon humble avis, il serait pertinent pour Fomus de se concentrer sur l’export lilypond.

Mais bon, suis-je vraiment impartial ? :-)

[9Bon, d’accord, une note est aussi un son. Mais vous m’avez compris.

[10Bien qu’aucune licence ne soit spécifiée, ce qui ne les rend pas redistribuables... et me rend coupable de multiples violations de droit d’auteur :)

Messages

  • Très beau sujet qui donne encore plus de vie à Lilypond... Mais ça en est où ? Il y a quelques temps, j’avais pensé à une interface simple utilisant les possibilités de base de lilypond (variables, transposition, modification du rythme) pour composer facilement de la musique à partir de motifs. Ayant vu ça il y a peu, http://www.hyperscore.com/ , je m’étais dis que ça devrais être possible de faire pareil, plus simple et surtout libre ! Mais je n’avais pas imaginé que tant de compositeurs y avaient déjà songé ! Merci pour la traduction. Raphaël

  • Il y a quelques dizaines d’années, j’ai suivi un stage sur les statistiques dans lequel le conférencier donnait pour exemple de la puissance de ces traitements celui de la synthèse de musique : après une analyse statistique d’une partition de Mozart (je ne me souvient plus de quel concerto), un algorithme permettait de reproduire « du Mozart » au kilomètre.

    Ce sujet m’intéresse pour une application très différente, la simulation des vibrations mécaniques sur les matériels transportés sur divers véhicules .

    Quelqu’un aurait-il des informations sur ce type d’analyse musicale, sur les logiciels éventuels ?

    Merci

  • C’est un bon projet. Nous l’aimons beaucoup. http://www.amerisleep.com/

Un message, un commentaire ?

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Vous n'êtes pas un robot ? Alors veuillez répondre à cette question essentielle :
Quelle est la moitié du mot «toto» ? 

Ajouter un document