Julien Vincenot (https://julienvincenot.com/) est compositeur et chercheur, actuellement en doctorat de composition à l’université de Harvard sous la direction de Chaya Czernowin et Hans Tutschku. Spécialiste de la composition assistée par ordinateur (CAO, ou CAC: computer-aided composition), son introduction donne un bel aperçu de l’historique de la discipline et de ce qu’elle est devenue aujourd’hui. Nous avons conservé le deuxième chapitre qui s’adresse à un lecteur spécialisé. Le troisième chapitre présente la librairie MOZ-LIB, qui est au contraire destinée aux débutants en CAO, et qu’il présentera plus en détail dans le prochain numéro.
Ce texte est la traduction d'un article présenté lors de l'International Computer Music Conference organisée au Conservatoire de musique de Shanghai en Octobre 2017.

ABSTRACT L'auteur décrit une stratégie visant l’implémentation d’applications Common Lisp pour la composition assistée par ordinateur au sein de Max, pour enrichir les possibilités offertes par la bibliothèque bach. En parallèle, une discussion plus large est ouverte sur l'état actuel de la discipline, et certaines mises en application sont présentées.

1. INTRODUCTION Ce qu’on appelle aujourd’hui composition assistée par ordinateur (CAO) existe depuis des décennies. Après les pionniers de la musique algorithmique, l'émergence des premières interfaces graphiques a permis à la discipline de se développer dans plusieurs directions. La CAO existe aujourd'hui sous différentes formes, différents langages et différents outils mis à la disposition des compositeurs.
Cette tendance s'est cristallisée autour d’environnements de programmation visuelle tels que OpenMusic (OM) et PWGL, tous deux issus du programme PatchWork (ou PW) conçu par Mikael Laurson à la fin des années 1980 [5]. Une des spécificités de cette famille de programmes, mais aussi celle de nombreuses autres depuis lors¹ , est que son intégralité est construite sur le même langage : Common Lisp² .
Depuis les débuts de l'intelligence artificielle, Lisp a toujours été considéré comme un langage particulier, et il ne fait pas l’unanimité des développeurs professionnels. Cependant, l'intérêt des musiciens n'a jamais complètement décliné. Cela est probablement dû à la facilité inhérente à Lisp de représenter, par le biais de listes imbriquées (voir fig. 1), les structures hiérarchiques de la notation musicale, mais aussi tout type de code conceptuel. Lisp possède par ailleurs plusieurs atouts : sa syntaxe claire et élégante, son efficacité à travailler avec la récursion (un concept puissant qui a de nombreuses applications concrètes dans le domaine musical), et sa capacité à générer du code de manière dynamique par le biais de macros.

Figure 1. Un objet Score dans PWGL et sa représentation interne sous la forme d'une liste ou d'un arbre de liens Lisp.

On pourrait dire que les innovations les plus récentes en matière de systèmes interactifs et traitement du son en temps réel, ainsi que le développement de divers modes de représentation et de contrôle, ont poussé cet outil à l’arrière-plan de la musique par ordinateur. D'une certaine manière, cela est compréhensible, car les approches purement symboliques, principalement dédiées à la notation traditionnelle, concernent une minorité de musiciens.
Néanmoins, on peut observer aujourd'hui un réel intérêt pour le renouvellement de ces paradigmes. La CAO comme discipline traverse une phase de transition, avec l'émergence de nouveaux outils orientés vers le temps réel, l'interactivité et des performances telles que le "mode réactif" dans OpenMusic [4], et bien sûr la librairie bach pour Max, développée par Andrea Agostini et Daniele Ghisi [1].
Tous ces développements récents sont prometteurs et nous ne pouvons pas encore imaginer les applications qui en émergeront, en particulier pour la conception de partitions et formes ouvertes/génératives en composition, et pour les installations interactives en particulier. Mais surtout, ils redéfinissent profondément l'accès à ces outils pour le travail "hors temps" du compositeur, ainsi que la distance entre concept et réalisation.

2. CAO EN LISP TEMPS-RÉEL
2.1. Lisp vs librairie bach
Toute mon activité de compositeur, au cours de la dernière décennie, a évolué autour de PWGL. Je ne l'utilise pas seulement comme un moyen de générer et de transformer des précompositions mais aussi comme un espace de travail, favorisant une certaine lenteur, un éloignement du matériau, afin de m’aider à penser la musique en général [7]. Comme OM, PWGL peut être considéré comme un environnement visuel pour programmer en Lisp, donc j'ai fini par apprendre à programmer directement en code Common Lisp, et c’est devenu pour moi un moyen très naturel de manipuler des idées musicales.
Ma première approche de la librairie bach a été problématique, compte tenu de ma pratique en CAO jusqu'à présent. Bien qu'il emprunte une partie de ses références à l’univers Lispien, il a été clairement conçu par ses créateurs avec d'autres paradigmes à l'esprit, assez loin du Lisp. La proximité avec la famille PW n'était qu'une façade, et j'étais réticent à m’y plonger plus sérieusement. Cependant, alors que je concevais le prototype d'un ensemble d'outils pédagogiques qui allait devenir MOZ'Lib (voir ci-dessous), j'ai été de plus en plus séduit par les immenses possibilités de la librairie, en termes d'interactivité et de composition exploratoire.
Ce n'est donc que plus tard que j'ai réalisé son pouvoir caché en tant que langage. bach s'appuie fortement, comme principale structure de données, sur ses bien nommées "lisp-like linked lists" (ou lllls), qui empruntent la structure parenthésée de Lisp, Structure fondamentale, comme je l'ai déjà expliqué, pour représenter des données musicales de manière hiérarchique. Mais les lllls ont également une caractéristique inattendue : elles peuvent être "détournées" pour générer un code Lisp complet en temps réel.

2.2. Une langue de plus pour Max ?
A ce stade, on peut s'interroger sur l'intérêt d’introduire un langage en apparence désuet tel que le Lisp dans Max. En plus de la possibilité d'écrire de nouveaux objets en C avec le SDK dédié, les utilisateurs de Max ont déjà accès à plusieurs langues intégrées : Gen~, Lua, Javascript, Node.js et Java. Ce qui s'est avéré très utile lorsqu’on se heurte aux limites de la programmation visuelle, en particulier dans le cas des structures de contrôle telles que les boucles et la récursion.
Comme nous le verrons plus loin, offrir à Max un pont stable avec Common Lisp n'enrichit pas seulement les possibilités de la librairie bach -- lui donnant ainsi accès à 40 ans de formalisation et de techniques de composition, à partir de plusieurs paradigmes esthétiques et informatiques -- mais permet également de “ressusciter” une myriade de pratiques historiques qui étaient limitées aux environnements de travail en "temps différé” (donc non en temps réel).
En effet, Lisp a déjà été accessible dans Max grâce à une bibliothèque antérieure, MaxLISPj³ , développée par Brad Garton. Dans cette approche, l'interprète Lisp, ABCL (Armed Bear Common Lisp), une implémentation basée sur une machine virtuelle Java, a été encapsulée dans l’objet mxj et tournait directement dans Max. Il y avait donc un risque de ralentissement ou même de crash de Max en cas de mauvaise programmation. En outre, l'auteur a souligné que la stabilité de son implémentation n'était pas garantie en cas de calculs lourds. Enfin, la sortie de MaxLISPj ne pouvait pas dépasser 2 000 caractères en raison de la limite des messages Max, il était donc impossible d'évaluer des structures musicales complexes. Toutes ces raisons justifient la recherche d'une autre approche⁴.

2.3. Comment formater des expressions Lisp avec bach
Afin de générer facilement du code Lisp avec la librairie bach cet article propose une méthode assez simple. Le point de départ est l'objet bach.join (anciennement bach.append), qui est un équivalent de la vénérable fonction LIST en Lisp. Comme le montre la figure ci-dessous, l'objet a besoin de plusieurs arguments et attributs afin de formater correctement la notation Lisp, ou s-expressions. Premièrement, le nombre d'entrées doit tenir compte du nombre d'arguments en faveur de la s-expression, y compris le nom de la fonction elle-même. Donc (+ 1 2) nécessitera un bach.join avec 3 entrées.
L'attribut @set permet d'initialiser les arguments pour la liste : ici, nous définissons le nom de la fonction, bien sûr, mais aussi des constantes si nécessaire. Les deux attributs restants, @triggers 0 et @outwrap 1, permettent de s'assurer que chaque sortie est "hot" (c'est-à-dire qu'elle peut déclencher une évaluation), et que la liste qui en résulte est respectivement entre parenthèses. Il faut comprendre à ce stade que les objets bach, comme bach.join, n'émettent pas de messages Max standard, mais une sorte de pointeur appelé format "natif". Cela permet aux objets bach d’échanger lllls sans pratiquement aucune limitation de la taille ou la profondeur.

Figure 2. Formatter du code Lisp avec bach.join

Dans cet exemple, la liste est convertie au format "texte", avec l'objet bach.portal, uniquement à des fins d'illustration. Deux objets bach.join sont combinés pour produire un s-expression, prêt à être envoyé à un interprète Lisp. La modification des valeurs dans les cases numériques mettra immédiatement à jour l'expression-s, transformant les constantes en variables. De la même manière, on pourrait entrer un symbole ou une liste pré-formatée à l'aide de la fonction de citation, en évitant que l'interprète ne les confonde avec un nom de fonction incorrect.⁵

2.4. Évaluations à la volée
De toute évidence, la génération dynamique de code Lisp à la volée a peu d'intérêt s’il ne produit aucun résultat. Après plusieurs essais⁶ , une stratégie nécessitant l'utilisation de SBCL (Steel Bank Common Lisp)⁷ en parallèle avec Max a été conçu. L'interpréteur Lisp est appelé dans Max via une interface en ligne de commande, avec l'aide de l’external shell⁸ sur macOS (une approche similaire est envisagée pour Windows 10). À ce stade, l'objet bach.write est utilisé pour transcrire le code généré en un fichier texte temporaire, avec l’extension .lisp. Cette opération est assez immédiate et il n’y a pas de limite à la taille du script, grâce au format lllls. Le script est alors prêt à être évalué avec la commande shell suivante :
sbcl --script path-of-script.lisp
Pour recevoir le résultat dans Max, les choses se compliquent. En effet, l'objet shell renvoie une chaîne de caractères de taille limitée, que nous ne pouvons pas utiliser pour des résultats excédant quelques caractères. La solution à ce problème est d'écrire finalement le résultat de notre code dans un autre fichier temporaire, directement depuis SBCL. Pour ce faire, j’ai créé une simple abstraction Max, pw.eval-box, qui est au centre de la librairie MOZ (voir ci-dessous).
Son but est de compléter notre code Lisp juste avant qu'il ne soit envoyé au bach.write, en ajoutant quelques s-expressions. Ce supplément de code permet de s'en assurer :
- le paquet Lisp pour l'évaluation est défini par la fonction in-package, permettant de travailler avec une bibliothèque d’utilisateurs (voir ci-dessous) ;
- la variable globale *random-state* est initialisée à chaque évaluation, en empêchant que des processus aléatoires rendent toujours les mêmes valeurs;
- finalement, le résultat est inscrit dans un autre fichier temporaire à une place définie.
Chaque fois que l'évaluation est terminée, la deuxième sortie de l'objet en shell renvoie un bang. Ceci est utilisé pour déclencher un bach.read pour importer le contenu du fichier temporaire résultant. C'est maintenant à l'utilisateur de décider quoi faire avec ces nouvelles données : contrôle des processus en temps réel dans Max lui-même, ou affichage de résultat en notation standard avec bach.roll ou bach.score par exemple. Bien entendu, en cas de besoin, on peut interrompre toute évaluation sans fin en envoyant le message pkill à l'objet shell. De toute évidence, cette approche n'est pas en temps réel, en soi, puisqu'elle s'appuie sur des fichiers temporaires et doit attendre que la SBCL rende un résultat pour que Max le lise. La latence entre les deux étapes est minime selon notre expérience, même avec de lourds calculs, et reste assez proche de l'exécution en pur SBCL, ce qui permet l'implémentation du système à l'intérieur d’applications réactives. Toutefois, un certain retard peut être parfaitement acceptable -- en fonction du but de l'évaluation, de la complexité du scénario et de la durée du résultat -- si tant est qu’une telle complexité dans les algorithmes soit pertinente dans un contexte artistique donné.

2.5. Vocabulaire étendu
Comme mentionné précédemment, il est possible avec la pw.evalbox de spécifier un paquet de démarrage pour nos évaluations. Pour Common Lisp, les paquets sont un moyen de définir les espaces de noms lors du codage. Par exemple, cette fonction est fréquemment utilisé dans OM et PWGL pour éviter les conflits entre plusieurs bibliothèques d'utilisateurs, dans le cas où certaines fonctions ou variables porteraient le même nom. La richesse d'environnements comme ceux de la PWGL et de la OM réside précisément dans la multitude de bibliothèques qu'ils ont apportées au public au cours des dernières décennies, allant de techniques très personnelles de compositeurs tels que Tristan Murail (Esquisse) ou Brian Ferneyhough (Combine), à des systèmes plus généraux de génération ou d'analyse de la musique. Ce ne sont que quelques exemples d'une grande variété de recherche dont le champ d'application pourrait être considérablement élargi grâce aux interfaces en temps réel.
SBCL permet d'utiliser un environnement prédéfini à la place de celle prévue dans la distribution officielle. La fonction save-lisp-and-die (du paquet SBCL sb-ext) peut stocker n'importe quel ensemble de paquets, ou de fonctions et variables comme une image binaire, ou un fichier .core. Par conséquent, une image nouvellement générée comprendra toutes les fonctions standard de common lisp et LCCB, étendues par ces définitions d'utilisateurs. Par conséquent, l'évaluation d'un script ne nécessitera l'installation que de deux fichiers sur la machine : l'exécutable SBCL lui-même et le fichier .core. Afin de charger SBCL avec un environnement donné, il suffit d'exécuter la commande suivante :

sbcl --core path-of-image.core --script path-of-script.lisp
Comme ce système est opérationnel, un travail d'adaptation des bibliothèques existantes de PWGL a été effectué :
- Le PMC⁹ de Mikael Laurson, le solveur de contraintes original de PatchWork (également connu sous le nom de PWConstraints) ;
- le CMIde Jacopo Baboni Schilingi, Profil (avec Mikhail Malt) et Contraintes ;
- Morphologie de Frédéric Voisin, un ensemble d'outils pour l'analyse des séquences symboliques, en explorant divers paradigmes.
La plupart de ces bibliothèques s'appuyaient sur plusieurs fonctions iconiques commune à la fois à l'OM et au PWGL (et héritée de PatchWork), tels que flat-once, x-append ou posn-match, dont les définitions ont été extraites et adaptées des sources d'OpenMusic¹⁰ . Aujourd'hui, une partie importante de ce lexique partagé, ainsi que les bibliothèques susmentionnées peuvent être utilisées comme exemple de fichier binaire de base fourni avec MOZ'Lib. Les sources sont accessibles sur simple demande à l’heure actuelle et seront incluses dans le pack Max dans un futur proche.
Un autre développement à long terme est en cours, en collaboration avec les compositeurs Örjan Sandred et Torsten Anders, afin de mettre à disposition le Cluster-Engine à Max avec la même méthode. Ce nouveau solveur de contraintes¹¹ , initialement développé par Sandred pour PWGL, permet de contrôler plusieurs voix musicales en parallèle en utilisant un réseau de moteurs de contraintes semi-indépendants --un pour chaque paramètre de chaque voix, y compris la structure métrique, les hauteurs et les rythmes. Les résultats de cette recherche, en termes de temps, de calcul et de flux de travail, sont déjà très prometteurs, et seront à terme l'objet d'une publication complète.

3. Applications
3.1. Une CAO intuitive pour enseigner la composition
Comme nous l'avons déjà mentionné, le besoin d'une interface Lisp appropriée dans Max est apparu lors du développement de MOZ'Lib¹² , un ensemble expérimental d'outils pédagogiques, conçu pour explorer simultanément l'écriture musicale, la création et la programmation informatique.
La librairie comprend plusieurs modules sous la forme de bpatchers - inspirés des modules BEAP et Vizzie apparus avec Max 7 - et principalement basés sur la librairie bach pour son interface. Chacun de ces modules représente une idée ou technique de composition, permettant à l'utilisateur d'interagir par diverses interfaces intuitives. Bien entendu, tous les modules peuvent être combinés entre eux, souvent de manière inattendue, pour imaginer et réaliser de nouvelles idées musicales.
Parmi ces modules, plusieurs n'auraient pas pu être mis en œuvre sans l'implication de Lisp. Par exemple, plusieurs techniques ont été directement empruntées aux librairies de Jacopo Baboni Schilingi (cf. ci-dessus). D’autres parties utilisent Lisp comme raccourci pour écrire des fonctions qui semblaient trop complexes ou trop spécifiques pour être traitées uniquement avec les objets bach. C'était le cas du module de rotation (voir fig. 3), qui utilise le solveur PMC de Mikael Laurson pour produire facilement une permutation circulaire d'une mélodie qui maintient de manière heuristique la forme globale de l’entrée d’origine.

Figure 3. Un simple patch utilisant trois modules de MOZ’LIB: draw_notes, see_notes et rotations

3.2. Renouveler une pratique avec un code préexistant
L'intérêt principal de cette approche est, à mon avis, d’étendre l'utilisation même des techniques de composition qui ont été initialement conçues pour un travail en "temps différé".
C'est le cas, bien sûr, de la plupart des processus créés avec PWGL et OM, mais encore plus avant PatchWork, alors que l'interface principale était le code Lisp lui-même. Un exemple parfait est un projet réalisé en collaboration avec le compositeur Jean-Baptiste Barrière, fondé sur sa bibliothèque personnelle Chréode [3]. La première version du code a été écrite au début des années 1980 à l'IRCAM avec Le Lisp (implémentation française du langage, développée par l'INRIA) à l'intérieur des environnements CHANT et FORMES. Chréode a été conçu avec l'ambition de réaliser "une grammaire de processus formels, une morphogenèse" [2], qui pourrait déterminer le comportement global de la synthèse sonore complexe ainsi que des partitions instrumentales.
Ce travail est parti d'une adaptation faite par Kilian Sprotte comme bibliothèque pour OM et PWGL. Le code original sur Le Lisp était presque indéchiffrable en raison de sa syntaxe très spécifique, très éloignée du Common Lisp qu’on connaît aujourd’hui. De plus, Chréode était principalement basée sur l’idée de programmation orientée-objet, son interface a dû être complètement réécrite à l’aide de CLOS (Common Lisp Object System).
D'une manière très similaire à MOZ'Lib, Max-Chréode consiste en une palette de bpatchers. Chacun d'eux, tout comme notre exemple de la figure 2, vise à générer un morceau de Lisp de façon dynamique. L'utilisateur a simplement besoin de connecter les boîtes selon les “règles” acceptées par le système. Le code entier est ensuite envoyé à une variante de pw.eval-box (evalchreodes), et le résultat peut être observé sous forme de graphiques (plot~) ou les partitions en temps réel.

Figure 4. Un simple patch utilisant des objets Max-Chréode, sur deux paramètres, montrant la génération du code (et leur sortie en commentaire), et la représentation graphique en sortie avec plot~

Un dernier exemple d’application est lié au projet Pre-Tensio, par les compositeurs Colin Roche et Jacopo Baboni Schilingi. Ce projet, situé à la lisière entre installation et performance, vise à représenter la tension créative ressentie par les compositeurs au cours de leur processus de travail. Développé à l’initiative de Colin Roche, Le Livre des Nombres s'appuie fortement sur Max et Lisp pour son dispositif interactif. La performance, d'une durée de 24 heures, a déjà été présentée dans plusieurs galeries d'art à Paris. Le compositeur, équipé de capteurs de rythme cardiaque, écrit de la musique à la table, qui est elle-même équipée de microphones de contact. Le public peut écouter, au moyen d'un casque, une amplification du battement cardiaque du compositeur, ainsi que les différents sons produits par son stylo sur le papier.
En parallèle, un patch Max enregistre l'évolution du battement cardiaque du compositeur sur une longue période, et finit par déclencher une analyse sur SBCL, pour révéler son profil général. Ensuite, le scénario traduit cette morphologie en une série de tempi modulant dans le temps, et la longue liste qui en résulte est imprimée automatiquement à la réception comme une métaphore du coût en temps passé par le compositeur au travail. Des fragments de ces grandes partitions de silence sont finalement transcrits à la main, en notation standard, et offerts au public.

4. ÉVALUATION
Plusieurs améliorations de cette approche devront être apportées. Le manque de transparence du processus en cours, exacerbé par l'utilisation d'un fichier binaire .core comme système de mémoire exige de plonger dans les sources pour obtenir une meilleure compréhension. Pour l'utilisateur, cela implique, bien sûr, une familiarité avec Common Lisp lui-même, mais aussi avec les fonctions spécifiques qui pourraient être invoquées.

Figure 5. Example de “reçu” généré et manuscrit des transcriptions pour Le livre des Nombres (avec l’aimable autorisation du compositeur @ Colin Roche 2016)

Un effort important de documentation et de diffusion aiderait un public plus large à acquérir ces outils. Comme déjà mentionné, une distribution sous forme de package Max constituerait une nette amélioration pour en faciliter l'installation. Un moyen d’accéder directement dans Max à la chaîne de documentation de toute fonction Lisp concernée, mais aussi à une liste de toutes les bibliothèques dans son environnement serait également très utile afin de réduire au minimum le phénomène de "boîte noire".
De plus, il est encore relativement difficile de déboguer du code Lisp dans Max. Pour les petites erreurs, il est possible de récupérer le résultat de toute fonction d'impression de la première sortie du shell externe, qui n'est pas utilisée autrement. Cependant, le débogueur SBCL rend difficile l’accès aux erreurs imbriquées plus profondément. Il est donc nécessaire pour travailler en parallèle sur le terminal ou sur un IDE (éditeur de texte) tels qu'Emacs ou SublimeText, pour identifier où un problème se produit dans un fichier temporaire donné.
En tout cas, ma propre pratique jusqu'à présent a été de faire des prototypes directement dans PWGL, avant de commencer à les traduire dans Max avec des objets bach. C'est là que se trouve une limite de cette approche qui a été soulignée par Jean-Baptiste Barrière après son expérience avec Max-Chréode : le patching avec des générateurs de code peut apporter une confusion entre les aspects sémantiques et pragmatiques d'une abstraction. Bien que le patch dans PWGL semble très similaire à Lisp (puisque le lexique et les règles sont à peu près les mêmes), chaque boîte renvoie en fait son propre résultat après évaluation. En revanche, les générateurs de code ne renvoient rien d'autre que code Lisp imbriqué, ce qui rend le patching direct plus cryptique.
De plus, la dépendance à l'égard du shell externe est toujours problématique. Comme il n'y a pas de soutien officiel de la part de Cycling'74 pour l'interface de ligne de commande, l'avenir de ces technologies n'est pas garanti et repose, au moins pour l'instant, sur la bonne volonté de la communauté des utilisateurs.

5. CONCLUSION
J'ai présenté une méthode pour évaluer du code Lisp en temps réel dans un environnement comme Max, en montrant les différents avantages de cette syntaxe supplémentaire, non seulement pour les utilisateurs existants de la communauté CAC mais aussi pour développer des applications interactives nécessitant l'exécution d'algorithmes de haut niveau en arrière-plan. De nombreuses autres possibilités que celles couvertes dans cet article pourraient être imaginées, par exemple le contrôle des processus audio en temps réel, la transformation ou la synthèse, à l'aide d'un code Lisp sophistiqué.
J'appartiens à une petite communauté de compositeurs qui est vraiment attachée à la CAC en général, et à PWGL en en particulier, comme environnement de travail privilégié. Ce développement ne vise manifestement pas à remplacer OM ou PWGL, mais vise au contraire à rendre leur possibilités accessibles dans desÒ contextes différents.
Cependant, on ne peut pas nier que les environnements Lisp dédiés à la CAC sont aujourd'hui dans une situation délicate comparée au reste de la musique informatique, et qu'ils survivent difficilement dans des contextes socio-économiques qui ne comprennent pas pourquoi ils comptent. Dans le cas où ils viendraient à disparaître, une telle initiative pourrait être considérée comme une mesure de préservation de l'héritage de générations de compositeurs et de chercheurs. Tout comme les esquisses, les partitions et les enregistrements, les environnements logiciels, qu’ils prennent la forme de patchs Max ou code Lisp, ils sont un support pour les connaissances artisanales et l'expression artistique que nous nous efforçons ici de préserver.

6. REFERENCES
[1] Andrea Agostini & Daniele Ghisi, « Real-Time Computer-Aided Composition with bach », in Contemporary Music Review, 1(32), 2013.
[2] Jean-Baptiste Barrière, « L’informatique musicale comme approche cognitive: simulation, timbre et processus formels », in La musique et les sciences cognitives, Ed. S. McAdams & I. Deliège, Pierre Mardaga, Brussels, 1988.
[3] Jean-Baptiste Barrière, « “Chréode”: the pathway to new music with the computer », in Contemporary Music Review, 1(1), 1984
[4] Jean Bresson & Jean-Louis Giavitto, « A Reactive Extension of the OpenMusic Visual Programming Language », in Journal of Visual Languages and Computing, 4(25), 2014.
[5] Mikael Laurson, PatchWork: A Visual Programming Language and some Musical Applications, PhD thesis, Sibelius Academy, Helsinki, 1996.
[6] Örjan Sandred, « PWMC, a Constraint-Solving System for Generating Music Scores », in Computer Music Journal, 34(2), 8-24, 2010.
[7] Julien Vincenot, « On “slow” computer-aided composition », in The OM Composer’s Book Vol.3, Ed. J. Bresson, C. Agon & G. Assayag, Éditions Delatour / IRCAM- Centre Pompidou, Paris, 2016.

¹ On peut citer par exemple Common Music ou plus récemment OpusModus, qui s'appuient tous deux sur une interface de programmation textuelle, cf. commonmusic.sourceforge.net | opusmodus.com
² L'un des plus anciens langages de programmation, le LISP (pour "list processing") a été conçu à l'origine par John McCarthy en 1958. Le Common Lisp est l'un des nombreux dialectes Lisp dérivés de la langue originale, standardisé au début des années 1980, et l'un des plus populaires avec le LISP de Scheme, Clojure et Emacs.
³ cf. http://sites.music.columbia.edu/brad/maxlispj/
⁴ Lisper, une bibliothèque développée par Alex Graham entre 2011 et 2013, a poursuivi un objectif similaire. Cette approche, contrairement à MaxLISPj, s'appuyait sur le protocole OSC pour établir une communication entre Max 4 ou 5 et une implémentation Lisp telle que Clozure CL. Ce travail n'ayant été porté à la connaissance de l'auteur que récemment, aucune comparaison claire n'a pu être établie entre cette approche et celle décrite dans cet article. Cependant, l'utilisation d'un tel protocole de réseau sera soigneusement étudiée pour les développements futurs, ainsi que son impact possible, positif ou négatif, sur la facilité d'utilisation pour les utilisateurs moyens du système. Cf. https://github.com/thealexgraham/lisper
⁵ Une règle de Lisp est que toute s-expression doit commencer par un appel de fonction, sinon elle renvoie une erreur. (+ 1 2) est correct car le symbole + est compris comme une fonction. La liste plate (1 2 3), en revanche, retournera une erreur puisque son premier élément 1 n'est pas une fonction. La syntaxe correcte utiliserait la fonction de liste (liste 1 2 3) ou la notation de citation : '(1 2 3) ou (citation (1 2 3)). De même, un symbole unique comme foo doit être mis entre guillemets "foo ou (quote foo)", sinon il sera interprété comme une variable non liée. En d'autres termes, la citation permet de transformer un morceau de code en une donnée.
⁶ Cette approche a d'abord été discutée à l'IRCAM à l'occasion de la réunion internationale PRISMA 2015. Plusieurs membres avaient remarqué que, dans certaines conditions, les calculs lourds étaient vraiment difficiles à gérer par PWGL ou OM, mais seraient évalués sans problème en Lisp pur. Une première stratégie consistait à utiliser sprintf pour formater le code Lisp, mais elle est rapidement devenue problématique pour de multiples raisons (interface utilisateur confuse, stabilité compromise par la gestion de la mémoire des symboles dans Max, etc.) Cette méthode a été explorée pendant plusieurs mois en collaboration avec les compositeurs Örjan Sandred, Hans Tutschku, Johannes Kretz et Jacopo Baboni Schilingi, puis optimisée et standardisée par l'auteur.
⁷ Il est évident que toute implémentation de Common Lisp, accessible via une interface de ligne de commande, pourrait être utilisée à la place. La SBCL est l'une des implémentations les plus populaires aujourd'hui : elle est à code source ouvert, multiplateforme et offre de grandes performances. Clozure CL est une bonne alternative, et offre des avantages similaires. Cf. www.sbcl.org | ccl.clozure.com
⁸ Cet objet externe a été initialement développé par Bill Orcutt, puis mis à jour par Jeremy Bernstein en 2013. Cf. cycling74.com/toolbox/bernstein-shell/
⁹ Il faut noter ici que, puisque PWGL est gratuit mais non open-source, le code du PMC n'est accessible que sous la forme d'un portage partiel réalisé par Örjan Sandred pour OpenMusic, sous le nom de OMCS.
¹⁰ Je profite de l'occasion pour remercier l'équipe des Représentations musicales de l'IRCAM, pour avoir rendu ces sources accessibles au public.
¹¹ Le Cluster-Engine est le successeur des bibliothèques de Sandred OMRC et PWMC [6], respectivement pour OM et PWGL.
¹² MOZ'Lib est actuellement maintenu par l'auteur en collaboration avec le compositeur Dionysios Papanicolaou. Il a été initialement soutenu par Ariane# (financé par la région Franche-Comté dans l'est de la France), une initiative axée sur l'extension de la pédagogie à l'aide des outils numériques. Pour une introduction générale à MOZ'Lib, cf. bachproject.net/2016/10/15/mozlib/

Copyright : © 2017 article en libre accès distribué selon les termes de la licence Creative Commons Attribution License 3.0 Unported, qui autorise l'utilisation, la distribution et la reproduction sans restriction sur tout support, à condition que l'auteur original et la source soient mentionnés. Cet article est traduit des proceedings de ICMC 2017 - International Computer Music Conference. Lien vers la publication originale:
https://quod.lib.umich.edu/i/icmc/bbp2372.2017.012/--lisp-in-max-exploratory-computer-aided-composition-in-real?view=image

Julien Vincenot

© L'ÉDUCATION MUSICALE 2021