M7) Le paysage des langages musicaux formels

De MUSIC V à TidalCycles — où se situe BP3 ?

Plus de vingt langages, sept décennies, un même but : donner à la musique un langage formel. Visite guidée d’un paysage vaste, fragmenté — et d’une niche que seul BP3 occupe.

Où se situe cet article ?

Dans M3, nous avons dressé la carte des six niveaux d’abstraction musicale — du signal brut (niveau 1) au pattern fonctionnel (niveau 6). Dans I3, nous avons présenté SuperCollider, le couteau suisse qui traverse ces niveaux. Mais SuperCollider n’est pas seul. Le paysage des langages musicaux formels est vaste, hétérogène, et aucun article ne le cartographie entièrement.

C’est l’objet de cet article : parcourir ce paysage, positionner chaque langage sur la carte de M3, et comprendre pourquoi BP3 occupe un territoire que personne d’autre n’habite. Cet article prépare le terrain pour M11 (à venir), qui explorera en profondeur la filiation entre BP3 et TidalCycles.

Pourquoi c’est important ?

Choisir un langage musical, c’est choisir ce qu’on peut penser musicalement. Un compositeur dans Csound pense en signaux. Un live-codeur dans TidalCycles pense en patterns cycliques. Un utilisateur de BP3 pense en grammaires et en dérivations. Le langage ne transcrit pas la pensée musicale — il la façonne.

Le problème : le paysage est vaste mais fragmenté. Chaque communauté connaît son outil, mais les ponts entre eux sont rares. Comparer Faust et TidalCycles, c’est un peu comme comparer un microscope et un télescope — ils sont tous deux des instruments optiques, mais ils ne regardent pas dans la même direction.

L’idée en une phrase

Les DSL musicaux incarnent des compromis entre trois axes — expressivité structurelle, accessibilité, performance temps réel — et BP3 est le seul à combiner grammaires formelles, stochasticité native et polymétrie.

La généalogie : de MUSIC V à aujourd’hui

Tout commence en 1957, quand Max Mathews écrit MUSIC aux Bell Labs — le premier programme à générer du son par ordinateur. De ce tronc commun naissent plusieurs lignées parallèles :

  • La lignée signal : MUSIC V (1957) → Csound (1986) → Faust (2004). L’unité de base est l’échantillon audio. On pense en oscillateurs, en filtres, en enveloppes.
  • La lignée symbolique : Haskore (1996) → Euterpea (2013) → TidalCycles (2013) → Strudel (2022). L’unité de base est la note ou le pattern. On pense en structures, en transformations, en compositions.
  • La lignée CAO : Common Music (1989) → OpenMusic (1999) → PWGL (2002) → Opusmodus (2015). La composition assistée par ordinateur, née à Stanford et à l’IRCAM, où l’on programme des processus compositionnels en Lisp.
  • La lignée analyse : Humdrum (1988) → music21 (2010). L’unité de base est le corpus — on ne génère pas de la musique, on l’étudie.
  • La lignée notation : LilyPond (1996) → Abjad (2008). Le « LaTeX de la musique » — on décrit la partition, le compilateur la grave.

Entre ces lignées, des systèmes hybrides traversent les couches : Max/MSP (1988), SuperCollider (1996), ChucK (2003), Extempore (2011). Et en dessous de tout cela, un protocole relie presque tous les systèmes depuis 1983 : MIDI — la lingua franca de la musique numérique.

Et puis il y a BP3 (1992) — qui ne s’inscrit dans aucune de ces lignées. Son unité de base n’est ni le signal ni le pattern, mais la règle de réécriture. C’est cette singularité que le reste de l’article va éclairer.

TikZ diagram

Figure 1 — Généalogie des langages musicaux formels. Sept lignées : CAO (vert), signal (orange), hybrides (turquoise), symbolique (bleu), standards (brun), analyse (rouge), grammaires (violet). La lignée grammaires distingue la tradition de recherche (GTTM, Steedman, L-systèmes, EMI, GenJam — nœuds fins) du DSL opérationnel (BP3/BP2SC — nœuds épais). La connexion BP3 → TidalCycles (via [Bel2001]) traverse les lignées.

Visite guidée

Csound (Vercoe, 1986) — le vétéran

Csound est le descendant direct de MUSIC V. Créé par Barry Vercoe au MIT Media Lab, il sépare la description du son (orchestra — les instruments) de la description de la musique (score — les notes). C’est le paradigme « orchestra/score » qui a dominé la synthèse pendant 30 ans.

 

instr 1
  aOut poscil 0.5, 440
  outs aOut, aOut
endin
i 1 0 2    ; joue l'instrument 1 à t=0 pendant 2 secondes

 

Couche M3 : Signal (niveau 1). Csound opère au plus bas — il manipule directement la forme d’onde. Communauté : toujours active après 40 ans, avec des milliers de compositeurs et chercheurs. Limite : pas de concept de « structure musicale » — les patterns et les hiérarchies n’existent pas dans le langage.

Max (Puckette, 1988, IRCAM) — le dataflow visuel

Créé par Miller Puckette à l’IRCAM, Max est le premier environnement de programmation visuelle pour la musique. On connecte des boîtes par des câbles — le son circule comme de l’eau dans des tuyaux.

 

[mtof] → [osc~ ] → [*~ 0.5] → [dac~]

 

Couche M3 : Dataflow (niveau 2). Max route des flux audio et des messages de contrôle dans un graphe. Note historique : Max est devenu commercial (Cycling ’74, maintenant Ableton). Miller Puckette a créé Pure Data (Pd) comme alternative libre, avec la même philosophie. Limite : la polymétrie et la stochasticité existent, mais doivent être câblées manuellement — rien n’est natif.

OpenMusic (IRCAM, 1999) — la composition assistée

OpenMusic est un environnement de composition assistée par ordinateur (CAO), issu de la tradition du Lisp à l’IRCAM (PatchWork, puis OpenMusic). C’est un système visuel comme Max, mais orienté partition plutôt que signal : on manipule des objets musicaux (accords, séquences, rythmes) via des programmes graphiques.

 

;; Séquence de 3 notes en OpenMusic
(make-instance 'chord-seq
  :lmidic '(6000 6400 6700)  ; do-mi-sol en midicents
  :ldur '(500 500 500))       ; durées en ms

 

Couche M3 : Génératif (niveau 5), mais orienté notation. OpenMusic produit des partitions, pas du son directement. Il excelle dans la composition par contraintes — définir des règles (intervalles permis, densités harmoniques) et laisser le système chercher des solutions. Lien : issu de la tradition de Pierre Boulez et de la musique spectrale à l’IRCAM. Limite : pas de temps réel — c’est un outil de studio, pas de scène.

Common Music (Taube, 1989) — l’ancêtre algorithmique

Common Music est l’un des plus anciens environnements de composition algorithmique, créé par Heinrich Taube à Stanford (CCRMA). Écrit en Common Lisp, contemporain de BP3, il a défini le vocabulaire de la CAO avant qu’OpenMusic ne prenne le relais.

 

;; Common Music : séquence aléatoire de 12 notes
(process repeat 12
  output (new midi :keynum (between 60 84)
                   :duration (pick .25 .5)))

 

Couche M3 : Génératif (niveau 5). Common Music offre un scheduler intégré, des processus compositionnels (boucles, conditions, aléatoire), et des sorties MIDI/audio. Son livre Notes from the Metalevel (Taube, 2004) reste une référence en composition algorithmique. Force : a formé une génération entière de compositeurs (années 90–2000). Limite : communauté réduite aujourd’hui, supplanté par SuperCollider et OpenMusic. Mais son influence persiste — c’est l’ancêtre commun de toute la lignée CAO.

SuperCollider (McCartney, 1996) — le couteau suisse

Déjà présenté en détail dans I3. Ici, concentrons-nous sur ce qui le rend unique dans le paysage : son système de Patterns.

 

Pbind(
  \note, Pseq([0, 4, 7, 12], inf),
  \dur, 0.25,
  \amp, Prand([0.5, 0.8, 1.0], inf)
).play;

 

Les Patterns de SuperCollider (Pbind, Pseq, Prand, Pwrand…) constituent un sous-langage à part entière — un DSL (Domain-Specific Language — langage dédié à un domaine) au sein de SuperCollider. Ils permettent de séquencer des événements avec des choix aléatoires, des répétitions, des alternances.

Couche M3 : traverse les niveaux 1 à 6 (signal + événements + patterns). C’est sa force — et sa complexité. La stochasticité est disponible (Prand, Pwrand), mais la polymétrie reste partielle : il faut gérer manuellement la synchronisation de flux temporels indépendants.

ChucK (Wang & Cook, 2003) — le temps comme type

ChucK est le seul langage musical où le temps est un type natif du langage. Créé par Ge Wang et Perry Cook à Princeton, il introduit le concept de strongly-timed programming : le temps n’est pas un callback ni un sleep — c’est une valeur qu’on manipule comme un entier ou une chaîne.

 

SinOsc s => dac;
440 => s.freq;
1::second => now;   // avance le temps d'1 seconde

 

L’opérateur => (le ChucK operator) contrôle le flux de données et le flux temporel. 1::second => now ne « dort » pas — il avance explicitement le curseur temporel. Cette sémantique permet de créer des flux concurrents (shreds) avec un contrôle temporel précis au sample près.

Couche M3 : Hybride (niveaux 1–3). ChucK opère au niveau du signal avec synthèse intégrée, mais avec un contrôle événementiel et temporel sans équivalent. Force : live coding, enseignement (utilisé à Stanford, Princeton), concurrence déterministe via shreds. Limite : pas de patterns à la TidalCycles, pas de grammaires — le temps est précis mais les structures restent plates.

Haskore / Euterpea (Hudak, 1996/2013) — l’algèbre musicale

Paul Hudak (Yale) a posé la question : peut-on représenter la musique comme un type algébrique en Haskell ? Sa réponse, Haskore (1996), puis son successeur Euterpea (2013), définissent la musique comme un type récursif :

 

-- Euterpea : un arpège de do majeur
line [c 4 qn, e 4 qn, g 4 qn]

 

La musique est un arbre de combinateurs : line (séquence), chord (accord), Modify (transformation). On compose des transformations comme des fonctions mathématiques : transposition, inversion, mise en miroir.

Couche M3 : Fonctionnel/Pattern (niveau 6). L’approche est purement algébrique — pas de synthèse, pas de temps réel. Le son est produit par export MIDI. Force : la rigueur formelle est maximale — chaque opération a une sémantique précise dans le système de types de Haskell. Limite : pas de polymétrie native, pas de stochasticité, pas de performance live.

Faust (Orlarey/GRAME, 2004) — le DSP pur

Faust (Functional AUdio STream) est un cas à part : un langage fonctionnel pur dédié exclusivement au traitement du signal. Créé par Yann Orlarey au GRAME (Lyon), il compile vers C++, LLVM, WebAssembly, Rust — et génère des plugins VST, AU, CLAP.

 

import("stdfaust.lib");
process = os.osc(440) * 0.5;

 

Couche M3 : Signal (niveau 1) — et uniquement le signal. Faust n’a aucun concept de « note », de « rythme » ou de « séquence ». C’est un langage de traitement, pas de composition. Force : c’est l’un des rares DSL musicaux avec une sémantique formelle publiée — chaque programme Faust dénote une fonction $f : \mathbb{R}^n \to \mathbb{R}^m$. Limite : N/A pour la polymétrie, la stochasticité, ou les grammaires — ce n’est pas son domaine.

TidalCycles (McLean, 2013) — les patterns cycliques

TidalCycles (ou Tidal) est un DSL embarqué dans Haskell, créé par Alex McLean (Goldsmiths, University of London). Il représente la musique comme des patterns — des fonctions du temps vers des événements — manipulés par des transformations fonctionnelles.

 

d1 $ sound "bd [sn cp] hh*3"
d2 $ note "{0 3 7, 0 5}%4" # s "superpiano"

 

Couche M3 : Fonctionnel/Pattern (niveau 6). L’unité de base est le cycle — une durée fixe que les patterns divisent récursivement. La mini-notation (la syntaxe entre guillemets) permet d’exprimer polymétrie ({3 éléments, 2 éléments}) et stochasticité (?) en quelques caractères.

Filiation avec Bel : McLean cite [Bel2001] « Rationalizing Musical Time » dans 8+ publications (2007–2022). La représentation cyclique du temps, les ratios temporels, la polymétrie comme superposition de cycles — autant de concepts qui descendent conceptuellement du Bol Processor. Cette filiation sera explorée en détail dans M11.

Force : Tidal est le langage phare du mouvement Algorave — performances musicales où le code est projeté à l’écran. Avec ~200+ citations cumulées et ~1800 stars GitHub, c’est le DSL de live coding le plus influent. Limite : pas de structure hiérarchique — les patterns sont plats, sans arbre de dérivation.

Sonic Pi (Aaron, Cambridge, 2012) — l’éducation

Sonic Pi est un environnement de live coding basé sur Ruby, développé par Sam Aaron à l’Université de Cambridge en collaboration avec la Raspberry Pi Foundation. Son objectif : rendre la programmation musicale accessible à tous, y compris aux enfants.

 

live_loop :beat do
  sample :bd_haus
  sleep 0.5
end

 

Couche M3 : entre le niveau 3 (événementiel — sample, play, sleep) et le niveau 6 (patterns simples via live_loop). Force : installeur unique, interface intégrée, 140+ samples, documentation exemplaire, curriculum scolaire. ~2 millions de téléchargements. Limite : moins expressif que TidalCycles pour les patterns complexes — pas de polymétrie native, pas de mini-notation.

Extempore (Sorensen, 2011) — le compilateur en live

Extempore pousse le live coding à son extrême : c’est le seul système qui compile du DSP en temps réel. Créé par Andrew Sorensen, il embarque deux langages — Scheme pour le séquencement haut niveau, et xtlang pour le traitement du signal bas niveau — avec compilation JIT (LLVM) pendant la performance.

 

;; Extempore : synthèse FM recompilable en live
(bind-func dsp:DSP
  (lambda (in time chan dat)
    (* 0.3 (sin (* TWOPI 440.0
       (/ (i64tof time) SR))))))

 

Là où Sonic Pi ou TidalCycles envoient des messages à un moteur audio externe, Extempore modifie la fonction de synthèse elle-même pendant qu’elle joue. On peut réécrire un oscillateur en concert — la transition est instantanée, sans coupure.

Pour comprendre ce que cela signifie, il faut distinguer trois niveaux de contrôle en temps réel dans les systèmes musicaux :

Niveau Ce qui change Ce qui reste fixe Exemples
1. Paramètres Fréquence, cutoff, amplitude… Topologie du synthé Hardware (potentiomètres), SuperCollider .set, MIDI CC
2. Patterns Séquencement, notes, rythmes Topologie + moteur audio SuperCollider Patterns, TidalCycles, Sonic Pi
3. Topologie Le graphe DSP lui-même Rien — tout est recompilable Extempore (unique en logiciel)

Le niveau 1 est le modèle du synthétiseur classique : un Moog a un circuit figé (VCO → VCF → VCA), mais les potentiomètres modulent tout en continu. Les SynthDefs de SuperCollider fonctionnent exactement ainsi — les arguments sont les potentiomètres, le graphe est figé à la compilation. Le niveau 2 est celui du live coding habituel — on change ce qui est joué, pas comment le son est produit. Le niveau 3, celui d’Extempore, est radicalement différent : on recompile la fonction de synthèse pendant qu’elle tourne.

En hardware, les synthétiseurs modulaires (Eurorack, Buchla) approchent le niveau 3 — on recâble physiquement la topologie. Mais le recâblage est discret (on branche/débranche), pas continu et instantané comme la recompilation JIT d’Extempore. C’est cette unicité qui justifie sa place dans le paysage, même si 99% du live coding se joue aux niveaux 1 et 2.

Couche M3 : Signal + Génératif (niveaux 1–5). Extempore est le seul système logiciel à opérer au niveau 3 de contrôle — topologie libre recompilable en live. Force : pas de couture entre composition et synthèse. Limite : courbe d’apprentissage abrupte (xtlang ressemble à du C typé), communauté restreinte.

Strudel (McLean et al., 2022) — Tidal dans le navigateur

Strudel est le port JavaScript de TidalCycles, conçu pour fonctionner directement dans un navigateur web — zéro installation, même sémantique.

Couche M3 : identique à TidalCycles (niveau 6). Strudel hérite de la mini-notation, de la polymétrie native, de la stochasticité. Il fait le pont entre l’accessibilité de Sonic Pi (rien à installer) et l’expressivité de TidalCycles (patterns composables). C’est le signe que le modèle de patterns cycliques de McLean — lui-même inspiré de Bel — est devenu un paradigme de référence.

La notation programmable

LilyPond (Nienhuys & Nieuwenhuizen, 1996) — le LaTeX de la musique

LilyPond est au monde musical ce que LaTeX est au monde académique : un langage de description qui compile vers une partition de qualité professionnelle. Créé par Han-Wen Nienhuys et Jan Nieuwenhuizen, il utilise un format textuel lisible que le compilateur transforme en gravure typographique.

 

\relative c' {
  \time 3/4
  c4 e g | c2. |
  \key g \major
  b4 d g | b2.
}

 

Couche M3 : Notationnel (niveau 4). LilyPond ne génère pas de musique et ne produit pas de son — il grave des partitions. Mais son format textuel en fait un langage formel à part entière, avec sa propre grammaire (parsée par GNU Bison). Force : qualité de gravure inégalée, standard de facto pour les compositeurs qui programment, base d’Abjad (API Python). Limite : pas de synthèse, pas d’interaction — c’est un outil de publication, pas de création.

Les outils d’analyse

music21 (Cuthbert & Ariza, 2010) — l’analyse computationnelle

music21 est une anomalie dans le paysage : c’est le seul système majeur orienté vers l’analyse plutôt que la génération. Créé par Michael Cuthbert au MIT, c’est un toolkit Python pour la musicologie computationnelle — on y étudie des corpus, on n’y compose pas.

 

# music21

## Analyser une fugue de Bach
from music21 import *
bach = corpus.parse('bwv66.6')
key = bach.analyze('key')   # si mineur
bach.measures(1, 4).show()  # affiche les 4 premières mesures

 

Le contraste avec le reste du paysage est saisissant : là où tous les autres systèmes produisent de la musique, music21 la dissèque. C’est l’outil de prédilection de la musicologie computationnelle — analyse harmonique, détection de patterns mélodiques, statistiques sur des corpus de milliers d’œuvres.

Couche M3 : Analytique. music21 opère sur des représentations symboliques (partitions) mais en mode reconnaissance, pas génération. Force : corpus intégré (Bach, Beethoven, folk), outils d’analyse harmonique, mélodique, rythmique, interface avec LilyPond et MIDI. Plus de 2500 citations. Limite : pas de synthèse, pas de temps réel.

Les standards d’échange

Aucun des langages précédents n’existe dans le vide. Trois standards constituent l’infrastructure commune du paysage — les protocoles et formats que presque tous les systèmes parlent ou consomment.

MIDI (Smith & Kakehashi, 1983) — le protocole universel

MIDI (Musical Instrument Digital Communication) n’est pas un langage mais un protocole — un standard pour transmettre des événements musicaux (note on/off, vélocité, contrôleurs) entre instruments et logiciels. C’est le tissu conjonctif de tout l’écosystème : Csound, SuperCollider, BP3, TidalCycles, music21 — tous parlent MIDI.

Ses limites sont connues : résolution 7 bits (128 valeurs de vélocité), pas de concept de « phrase » ou d' »accord », pas de notation. Mais son universalité est inégalée après 40+ ans — c’est le seul standard que tous les systèmes du tableau supportent, directement ou indirectement.

MIDI 2.0 (2020) corrige les limites techniques après 37 ans : résolution 32 bits, articulation par note, échange de propriétés, rétrocompatibilité complète. La mise à jour résout les problèmes de résolution mais ne change pas le niveau d’abstraction fondamental — MIDI 2.0 reste un protocole d’événements, pas un langage structurel.

MusicXML (Good, 2004) — le PDF de la partition

MusicXML est au monde de la notation ce que PDF est au texte : un format d’échange standardisé pour les partitions. Créé par Michael Good (Recordare), maintenu aujourd’hui par le W3C Music Notation Community Group, il permet de transférer des partitions entre Finale, Sibelius, MuseScore, LilyPond — et d’y accéder depuis music21 ou Humdrum.

MusicXML encode la partition visuelle (portées, mesures, notes, dynamiques) en XML. C’est un format de description, pas un langage génératif — mais il est devenu le standard de facto pour l’interopérabilité des partitions numériques.

MIDI vs. MusicXML : MIDI encode la performance (quand appuyer sur quelle touche, à quelle vélocité). MusicXML encode la partition (quelle note, dans quelle mesure, avec quelle notation). Ce sont deux couches complémentaires — l’une événementielle (M3 niveau 3), l’autre notationnelle (M3 niveau 4). Ni l’une ni l’autre n’encode la structure musicale (M3 niveau 5) — c’est là que les DSL génératifs et BP3 interviennent.

Autres systèmes notables

Le paysage ne se limite pas à ces profils. Cinq systèmes méritent une mention pour leur influence ou leur originalité.

PWGL / Opusmodus — Successeurs d’OpenMusic dans la lignée CAO. PWGL (PatchWork Graphics Library), créé par Mikael Laurson à la Sibelius Academy (Helsinki, 2002), a étendu le paradigme visuel d’OpenMusic avec un éditeur de contraintes plus puissant et une intégration audio. Opusmodus (2015) poursuit dans cette lignée avec une interface Lisp modernisée et une documentation orientée compositeur. Couche M3 : Génératif (niveau 5).

Alda — Langage textuel ultra-accessible créé par Dave Yarwood (2015). Sa syntaxe minimaliste (piano: c d e f g a b > c) permet d’écrire de la musique comme du texte brut. Avec 5700 stars GitHub, c’est l’un des DSL musicaux les plus populaires — mais il n’a aucune publication académique. Le « Markdown de la musique » : parfait pour des esquisses rapides, limité pour la recherche.

Humdrum/\\kern — David Huron a créé en 1988 un toolkit Unix pour l’analyse musicale : chaque outil fait une chose (extraire des voix, compter des intervalles, chercher des motifs), et on les pipe ensemble. Le format \\kern encode la partition comme un tableau de colonnes temporelles (spines). Précurseur de music21, Humdrum reste utilisé en musicologie computationnelle pour sa philosophie modulaire et son vaste corpus encodé.

ABC notation — Le format le plus compact pour encoder la musique. |:GABc dedB| encode une phrase mélodique complète. Créé par Chris Walshaw (1991), c’est le standard de facto pour la tradition folklorique numérisée — des milliers d’airs irlandais, écossais et bretons encodés en quelques caractères. Pas un langage de programmation, mais un format d’une élégance remarquable.

Abjad — API Python pour LilyPond, créée par Trevor Bača et Josiah Wolf Oberholtzer (2008). Abjad permet aux compositeurs contemporains de générer des partitions complexes par programme — boucles, algorithmes, contraintes en Python, rendu en LilyPond. C’est le pont entre l’algorithmique et la gravure.

Les systèmes à grammaires — la tradition oubliée

BP3 n’est pas un ovni isolé. Il s’inscrit dans une tradition de systèmes qui utilisent des grammaires formelles pour modéliser la musique — une tradition souvent ignorée par les communautés des DSL musicaux.

GTTM (Generative Theory of Tonal Music, Lerdahl & Jackendoff, 1983) — Le cadre théorique fondateur. GTTM propose une grammaire générative de la musique tonale, avec des règles de bonne formation et de préférence pour les structures métriques, de groupement, de réduction temporelle et de prolongation. Ce n’est pas un logiciel mais un formalisme analytique — direction ANAL, pas GEN. Son influence théorique est immense, mais aucun système n’implémente GTTM de manière complète et utilisable.

Steedman (1984, 1996) — Mark Steedman a montré que les séquences d’accords jazz peuvent être décrites par des grammaires context-free. Ses travaux relient la linguistique formelle (grammaires catégorielles combinatoires) à l’analyse harmonique. Direction ANAL — ces grammaires analysent des grilles existantes mais ne génèrent pas de musique performable.

EMI / Experiments in Musical Intelligence (Cope, ~1987) — David Cope a créé un système qui simule des styles compositionnels via des réseaux de transitions augmentés et une base de données de signatures. EMI a produit des œuvres « à la Bach » ou « à la Chopin » qui ont trompé des experts. Direction GEN — mais le formalisme est plus proche des chaînes de Markov que des grammaires au sens strict.

GenJam (Biles, 1994) — Un système d’improvisation jazz qui combine algorithmes génétiques et grammaires. GenJam évolue des phrases musicales par sélection et mutation, guidé par des règles grammaticales. C’est l’un des premiers systèmes à marier grammaires et stochasticité — mais via l’évolution, pas via des poids décrémentaux comme BP3.

L-systèmes musicaux — Les L-systèmes (Lindenmayer, 1968), conçus à l’origine pour modéliser la croissance des plantes, ont été adaptés à la musique par plusieurs chercheurs (Prusinkiewicz, Worth & Stepney, McCormack). Le principe : des règles de réécriture parallèle génèrent des structures auto-similaires — fractales musicales. Plusieurs implémentations existent (en Max, SuperCollider, Python), mais aucune n’est devenue un DSL autonome.

BP3 se distingue de tous ces systèmes par trois traits : il est le seul à être un DSL utilisable (pas un cadre théorique), le seul à combiner grammaires et stochasticité native (poids décrémentaux, pas des algorithmes génétiques), et le seul à fonctionner dans les deux directions (GEN+ANAL). Les systèmes à grammaires musicales sont soit analytiques (GTTM, Steedman), soit génératifs (EMI, GenJam, L-systèmes) — jamais les deux.

Et bien d’autres… Le paysage inclut aussi Overtone (Clojure, ancêtre de Sonic Pi, 5800+ stars), FoxDot/Renardo (Python live coding), ixi lang (syntaxe minimaliste greffée sur SuperCollider), Gibber (JavaScript, précurseur web de Strudel), ORCA (séquenceur spatial 2D, 4900 stars), et Glicol (Rust + WebAssembly, le plus récent). Le tableau ci-dessous les intègre tous.

Tableau comparatif

Voici les 24 systèmes, positionnés sur les critères discriminants. Trois colonnes méritent une explication :

  • Formalisme : le modèle formel sous-jacent au langage — grammaire, algèbre, protocole, schéma, etc. Remplace les anciennes colonnes « Paradigme » et « Grammaires » en une seule information plus riche.
  • Stochasticité : native = intégrée au paradigme du langage (poids décrémentaux de BP3, ? de TidalCycles) ; intégrée = disponible via fonctions/objets du langage (Prand de SC, .choose de Sonic Pi) ; manuelle = nécessite un câblage explicite.
  • Direction : GEN = produit de la musique ; ANAL = analyse de la musique existante ; DESC = décrit/encode (notation, protocole) ; GEN+ANAL = les deux.
Langage Année Formalisme Couche M3 Polymétrie Stochasticité Direction Temps réel
MIDI 1983 protocole binaire 3-Événementiel — — GEN oui
Csound 1986 orchestra/score 1-Signal — — GEN oui
Humdrum 1988 spines tabulaires (Unix) Analyse — — ANAL —
Max 1988 graphe dataflow 2-Dataflow manuelle manuelle GEN oui
Common Music 1989 processus Lisp 5-Génératif — intégrée GEN —
ABC 1991 notation textuelle 4-Notation — — DESC —
BP3 1992 grammaires Type 2+ (MCSL) 5-Génératif native native GEN+ANAL via BP2SC
Haskore 1996 algèbre de Music (Haskell) 6-Fonctionnel — — GEN —
LilyPond 1996 CFG (GNU Bison) 4-Notation — — DESC —
SuperCollider 1996 OOP + Pattern DSL 1→6 partielle intégrée GEN oui
OpenMusic 1999 patches visuels (Lisp) 5-Génératif manuelle intégrée GEN —
PWGL 2002 patches visuels (Lisp) 5-Génératif manuelle intégrée GEN —
ChucK 2003 strongly-timed concurrent 1–3 — intégrée GEN oui
MusicXML 2004 XML Schema (W3C) 4-Notation — — DESC —
Faust 2004 sém. dénotationnelle 1-Signal N/A — GEN oui
Abjad 2008 API Python / LilyPond 4-5 — intégrée GEN —
music21 2010 API Python (toolkit) Analyse — — ANAL —
Extempore 2011 Scheme + xtlang (LLVM) 1–5 — intégrée GEN oui
Sonic Pi 2012 DSL impératif (Ruby) 3–6 manuelle intégrée GEN oui
Euterpea 2013 algèbre de Music (Haskell) 6-Fonctionnel — — GEN —
TidalCycles 2013 algèbre de patterns (Haskell) 6-Fonctionnel native native GEN oui
Alda 2015 notation textuelle 4-Notation — — DESC —
Opusmodus 2015 DSL Lisp 5-Génératif manuelle intégrée GEN —
Strudel 2022 algèbre de patterns (JS) 6-Fonctionnel native native GEN oui

La colonne Formalisme monte que si chaque langage a un modèle formel, seul BP3 repose sur des grammaires formelles au sens de Chomsky — des règles de réécriture qui définissent un langage musical entier. Faust a une sémantique dénotationnelle, Haskore une algèbre de types, TidalCycles une algèbre de patterns — mais aucun n’utilise le formalisme grammatical comme modèle de la musique elle-même. Combiné à la Direction GEN+ANAL, la Polymétrie native et la Stochasticité native, BP3 reste seul dans sa niche.

La niche de BP3

Encart : Pourquoi BP3 n’est PAS un DSL comme les autres

BP3 n’est pas un DSL au sens habituel. Ce n’est pas un langage de programmation dans lequel on écrit de la musique — c’est un système de grammaires formelles dans lequel on définit des familles de musiques. La différence est fondamentale : un programme TidalCycles produit un pattern. Une grammaire BP3 produit toutes les phrases d’un langage musical.

Et contrairement à music21 ou Humdrum, qui analysent de la musique existante, BP3 peut aussi vérifier qu’une séquence appartient au langage défini par la grammaire. Sur 24 systèmes, c’est le seul qui raisonne dans les deux directions.

TikZ diagram

Figure 2 — Positionnement des systèmes musicaux selon deux axes : grammaires formelles (horizontale) et stochasticité (verticale). À droite, la tradition grammaticale (GTTM, L-systèmes, Steedman, EMI, GenJam — nœuds fins violets) monte progressivement en stochasticité sans jamais atteindre la niche de BP3, qui combine grammaires natives + stochasticité native + polymétrie + bidirectionnalité.

Trois unicités

1. Grammaires formelles comme modèle musical. La génération de musique par grammaires existe depuis les années 1980 — L-systèmes de Prusinkiewicz, grammaires jazz de Steedman, EMI de Cope. Et plusieurs systèmes du tableau peuvent implémenter des grammaires : OpenMusic via des patches de contraintes, SuperCollider via des quarks dédiés, LilyPond utilise même une CFG (GNU Bison) pour parser son input. Mais dans tous ces cas, la grammaire est un outil parmi d’autres ou un détail d’implémentation. BP3 est le seul système du paysage où les règles de réécriture sont le paradigme natif (L1) : l’utilisateur écrit S → A B, A → do re | mi fa, et la musique dérive de ces règles — avec une sémantique opérationnelle formalisable par SOS (L6). C’est la seule approche où le pouvoir expressif est analysable : on peut positionner une grammaire BP3 dans la hiérarchie de Chomsky (Type 2+ / MCSL, voir L9).

2. Stochasticité native. Plusieurs langages offrent de l’aléatoire — Prand en SuperCollider, ? en TidalCycles, .choose en Sonic Pi. Mais BP3 va plus loin avec les poids décrémentaux (B4) : un poids qui diminue à chaque utilisation, garantissant que les choix se renouvellent sans intervention. Et le mode RND (B3) — choix aléatoire pondéré parmi les règles applicables — n’est pas un ajout : c’est intégré au mécanisme de dérivation lui-même.

3. Polymétrie native. TidalCycles et Strudel partagent ce trait — héritage direct de Bel. Mais BP3 exprime la polymétrie dans la grammaire elle-même : {3, do re mi, fa sol} signifie deux voix en ratio 3:2, avec des durées exactes en nombres rationnels (B5). Pas de quantification, pas d’approximation — les structures temporelles sont mathématiquement précises.

Et aussi : la bidirectionnalité

Au-delà de ces trois unicités, BP3 est le seul système musical du paysage à fonctionner dans trois directions (B8) :

  • PROD (production) : générer des phrases à partir d’une grammaire
  • ANAL (analyse) : vérifier qu’une séquence appartient au langage défini
  • TEMP (templates) : utiliser des wildcards analytiques pour accepter des familles de séquences

Cette bidirectionnalité — étudiée en détail dans L13 — n’a d’équivalent dans aucun des 24 systèmes du tableau. Le contraste est maintenant visible dans la colonne Direction : music21 et Humdrum analysent (ANAL), tous les autres génèrent (GEN), et BP3 est le seul à faire les deux (GEN+ANAL). C’est le signe que BP3 opère à un niveau d’abstraction différent : là où les autres langages exécutent de la musique, BP3 raisonne sur des langages musicaux.

music21 analyse ce que BP3 génère — mais chacun ignore l’autre direction. Un système idéal combinerait l’analyse de corpus de music21 avec la génération grammaticale de BP3. Cette complémentarité confirme le diagnostic de L13 : l’asymétrie génération/reconnaissance est un impensé fondamental du domaine.

Le triangle revisité

Dans M3, nous avions identifié un triangle de compromis : exhaustivité (tout encoder), compacité (peu de données), générativité (produire des variations). La plupart des langages sacrifient un axe :

  • Csound et Faust maximisent l’exhaustivité (signal complet) au prix de la générativité
  • TidalCycles et Euterpea maximisent la générativité (patterns infinis) au prix de l’exhaustivité
  • MIDI maximise la compacité au prix de tout le reste

BP3 est le seul à combiner compacité (une grammaire de quelques règles = un langage entier) et générativité (choix stochastiques, modes multiples) sans sacrifier l’expressivité structurelle (hiérarchies, polymétrie, flags). Et l’enrichissement du paysage renforce ce constat : ni ChucK (strongly-timed mais sans structure), ni Extempore (DSP compilé mais sans grammaires), ni Common Music (algorithmique mais sans bidirectionnalité) n’occupent ce territoire. Le prix : BP3 ne fait pas de synthèse — c’est le rôle de BP2SC (B7) et SuperCollider.

Ce qu’il faut retenir

  1. Six lignées historiques — signal, symbolique, CAO, analyse, notation, et hybrides — chacune avec sa propre unité de base (échantillon, pattern, processus, corpus, partition, flux).
  2. Le cadre de M3 organise le paysage : chaque langage opère à un ou plusieurs niveaux d’abstraction (signal, dataflow, événementiel, notationnel, génératif, fonctionnel).
  3. 24 systèmes, aucun ne couvre tout — SuperCollider s’approche le plus des six niveaux (1 à 6), Extempore compile du DSP en live, ChucK traite le temps comme un type natif.
  4. Quatre critères discriminent BP3 : grammaires formelles (unique), stochasticité native (poids décrémentaux), polymétrie native (ratios exacts), et direction bidirectionnelle (GEN+ANAL).
  5. TidalCycles est le plus proche cousin de BP3 — même intérêt pour la polymétrie, même inspiration (Bel2001) — mais avec un paradigme fondamentalement différent (patterns fonctionnels vs. grammaires de production).
  6. L’asymétrie génération/analyse est systémique : music21 et Humdrum analysent, tous les autres génèrent, et seul BP3 fait les deux. Cette fracture traverse tout le paysage.
  7. La bidirectionnalité est la niche ultime : sur 24 systèmes, BP3 est le seul à combiner grammaires + stochasticité + polymétrie + bidirectionnalité.

Pour aller plus loin

Références bibliographiques

  • Mathews, M. V. (1969). The Technology of Computer Music. MIT Press. — L’ouvrage fondateur (MUSIC V).
  • Vercoe, B. (1986). Csound: A Manual for the Audio Processing System. MIT Media Lab.
  • Puckette, M. (1991). « Combining Event and Signal Processing in the MAX Graphical Programming Environment ». Computer Music Journal, 15(3).
  • McCartney, J. (2002). « Rethinking the Computer Music Language: SuperCollider ». Computer Music Journal, 26(4).
  • Hudak, P. (1996). « Haskore Music Notation — An Algebra of Music ». Journal of Functional Programming, 6(3).
  • Hudak, P. (2014). The Haskell School of Music — From Signals to Symphonies. Cambridge University Press.
  • Assayag, G. et al. (1999). « Computer-Assisted Composition at IRCAM: From PatchWork to OpenMusic ». Computer Music Journal, 23(3).
  • Orlarey, Y., Fober, D. & Letz, S. (2004). « Syntactical and Semantical Aspects of Faust ». Soft Computing, 8(9).
  • McLean, A. (2014). Making Programming Languages to Dance to: Live Coding with Tidal. PhD Thesis, Goldsmiths.
  • McLean, A. & Wiggins, G. (2010). « Tidal – Pattern Language for the Live Coding of Music ». In Proc. FARM.
  • Aaron, S. & Blackwell, A. F. (2013). « From Sonic Pi to Overtone ». In Proc. FARM.
  • Roos, F. & McLean, A. (2022). « Strudel: Live Coding Patterns on the Web ».
  • Wang, G. & Cook, P. (2003). « ChucK: A Concurrent, On-the-fly Audio Programming Language ». In Proc. ICMC.
  • Taube, H. (1991). « Common Music: A Music Composition Language in Common Lisp and CLOS ». Computer Music Journal, 15(2).
  • Taube, H. (2004). Notes from the Metalevel: An Introduction to Computer Composition. Routledge.
  • Sorensen, A. & Gardner, H. (2010). « Programming with Time: Cyber-physical Programming with Impromptu ». In Proc. OOPSLA.
  • Cuthbert, M. S. & Ariza, C. (2010). « music21: A Toolkit for Computer-Aided Musicology ». In Proc. ISMIR.
  • Huron, D. (2002). « Music Information Processing Using the Humdrum Toolkit ». Music Perception, 20(1).
  • Nienhuys, H.-W. & Nieuwenhuizen, J. (2003). « LilyPond, a System for Automated Music Engraving ». In Proc. XIV Colloquium on Musical Informatics.
  • Laurson, M. & Kuuskankare, M. (2002). « PWGL: A Novel Visual Language ». In Proc. ICMC.
  • Trevino, J. (2013). « Compositional and Analytic Applications of Automated Music Notation via Object-Oriented Programming ». PhD Thesis, UCSD.
  • MIDI Manufacturers Association (1983). MIDI 1.0 Detailed Specification. — Le standard original.
  • MIDI Manufacturers Association (2020). MIDI 2.0 Specification. — Extension 32 bits, rétrocompatible.
  • Good, M. (2001). « MusicXML for Notation and Analysis ». In The Virtual Score, MIT Press.
  • Bel, B. (2001). « Rationalizing Musical Time: Syntactic and Symbolic-Numeric Approaches ».
  • Bel, B. & Kippen, J. (1992). « Modelling Music with Grammars ». In Understanding Music with AI, 207-238.
  • Lerdahl, F. & Jackendoff, R. (1983). A Generative Theory of Tonal Music. MIT Press.
  • Steedman, M. (1984). « A Generative Grammar for Jazz Chord Sequences ». Music Perception, 2(1), 52-77.
  • Cope, D. (1996). Experiments in Musical Intelligence. A-R Editions.
  • Biles, J. A. (1994). « GenJam: A Genetic Algorithm for Generating Jazz Solos ». In Proc. ICMC.
  • Prusinkiewicz, P. & Lindenmayer, A. (1990). The Algorithmic Beauty of Plants. Springer. — Chapitre sur la musique.

Liens dans le corpus

  • I3 — SuperCollider en détail
  • M3 — Les six niveaux d’abstraction
  • M11 — TidalCycles et la filiation Bel
  • B3 — Règles de dérivation et modes de BP3
  • B4 — Flags et poids décrémentaux
  • B5 — Polymétrie et structures temporelles dans BP3
  • B7 — Le transpileur BP2SC
  • B8 — Les trois directions de BP3 (PROD/ANAL/TEMP)
  • L1 — La hiérarchie de Chomsky
  • L13 — La dualité génération/reconnaissance

Glossaire

  • CAO : Composition Assistée par Ordinateur — approche où un logiciel aide le compositeur par des algorithmes, sans remplacer ses décisions. Lignée : Common Music → OpenMusic → PWGL → Opusmodus
  • Dataflow : paradigme de programmation où la computation est un graphe de flux de données entre nœuds de traitement
  • DSL : Domain-Specific Language — langage de programmation dédié à un domaine particulier (ici, la musique)
  • Gravure musicale : processus de mise en page d’une partition selon les conventions typographiques professionnelles. LilyPond automatise ce processus
  • JIT : Just-In-Time compilation — compilation du code au moment de l’exécution. Extempore utilise LLVM JIT pour compiler du DSP en live
  • Live coding : pratique performative où le musicien écrit ou modifie du code en temps réel devant un public
  • MCSL : Mildly Context-Sensitive Language — classe de langages entre context-free (Type 2) et context-sensitive (Type 1)
  • MIDI : Musical Instrument Digital Communication — protocole universel (1983) pour transmettre des événements musicaux entre instruments et logiciels. MIDI 2.0 (2020) étend la résolution à 32 bits
  • Mini-notation : syntaxe compacte de TidalCycles pour décrire des patterns rythmiques entre guillemets
  • MusicXML : format d’échange XML standardisé (W3C) pour les partitions numériques. Interopérabilité entre Finale, Sibelius, MuseScore, LilyPond
  • Pattern : en SuperCollider ou TidalCycles, objet qui génère des séquences de valeurs selon des règles
  • PCFG : Probabilistic Context-Free Grammar — grammaire hors-contexte enrichie de probabilités sur les règles
  • Polymétrie : superposition de structures métriques à ratios différents (ex. 3 contre 2)
  • Spines : dans Humdrum, colonnes verticales d’un fichier \\kern représentant chacune une voix ou une dimension musicale
  • Strongly-timed : paradigme de ChucK où le temps est un type natif du langage, manipulable comme toute autre donnée
  • Transpileur : programme qui convertit du code source d’un langage vers un autre de même niveau d’abstraction

Prérequis : M3, I3
Temps de lecture : ~20 min
Tags : #dsl-musicaux #tidalcycles #faust #sonic-pi #csound #supercollider #haskore #openmusic #bp3 #live-coding #grammaires-musicales #paradigmes-musicaux #chuck #common-music #extempore #music21 #lilypond #analyse-musicale

Prochain article : M11 — TidalCycles : quand le Bol Processor inspire le live coding

← Retour à l’index