BPscript · S11 · Conception
En live : modifier pendant que ça joue
Hot-swap, latence, granularité — BPscript comme instrument de scène
Publié le 21 mai 2026 · Read in English
Modifier pendant que ça joue
Hot-swap, latence, granularité
La plupart des outils jouent une musique écrite à l’avance. Avec BPscript, la musique se dérive en temps réel selon des règles — et ces règles, on peut les modifier pendant que ça joue.
Où se situe cet article ?
C’est l’article de synthèse : après avoir vu le langage (S2-S8), les couches (S9) et l’architecture (S10), on assemble le tout pour le live. Comment ça marche sur scène ?
Sept axes de modification indépendants
Le live coding avec BPscript, c’est modifier un ou plusieurs aspects de la scène pendant que la musique joue. Chaque couche est modifiable indépendamment :
| Ce qu’on modifie | Ce qui change | Ce qui reste |
|---|---|---|
Les acteurs (@actor) | Les rattachements alphabet/tuning/transport | La structure |
| La composition (règles, flags) | La structure temporelle | Les rattachements |
| L’alphabet (JSON) | Les noms de notes | Les fréquences |
| Le tuning (JSON) | L’accordage | Les noms de notes |
| Le tempérament (JSON) | La grille d’intervalles | La gamme |
| Le routage (JSON) | La destination | La musique |
| Les backticks (code) | La logique algorithmique | La structure |
C’est la même pièce, sept façons de la transformer en direct. Changer le tuning de shruti 22 (intonation indienne) à 12-TET, c’est un seul fichier JSON — la grammaire ne bouge pas, seules les fréquences changent (S9).
Ce qui se passe quand on modifie
Quand le compositeur modifie le fichier .bps en live :
- Le compilateur reproduit l’arbre de scène depuis le source modifié (~10 ms)
- BPx redérive l’arbre → nouvelle séquence de tokens datés (~50-100 ms pour une grammaire typique)
- Le dispatcher commence à router les nouveaux événements par acteur
- Les sessions de code continuent — leurs variables et leurs imports sont conservés
Le temps total : 50-100 ms pour une grammaire typique. Un humain ne perçoit pas un changement structurel de moins de 100 ms — c’est transparent.
Aujourd’hui, chaque opération re-dérive toute la scène. Sélectionner une scène, changer un drapeau ou relancer l’aléa reconstruit une instance du moteur et redérive l’ensemble. La couche live visée (le contrat du moteur la spécifie) pousserait au contraire des commandes atomiques à une instance vivante — poser un drapeau, un poids, un mode, émettre un déclenchement — sans tout redériver ; elle reste à câbler. La seule pièce « live sans redériver » déjà en chantier est la déformation de tempo, appliquée à l’émission (pas un recalcul de la grille).
Pour les grammaires profondes (polymétries récursives, nombreuses alternatives), la dérivation peut prendre plus longtemps. Dans ce cas, le système utilise un buffer (tampon) : les événements de la séquence précédente continuent à jouer pendant que la nouvelle séquence se calcule.
Périmètre : la chaîne va de la source à l’arbre de scène, puis à la dérivation par BPx (sortie = tokens datés, une projection de l’arbre). Le dispatcher, les transports et les sessions de code sont le consommateur aval de ces tokens. Cet article décrit le système complet.
Granularité : quand le changement prend-il effet ?
Trois stratégies possibles :
| Stratégie | Comportement | Analogie |
|---|---|---|
| Quantisé | Le changement prend effet au prochain cycle de dérivation | Comme TidalCycles qui quantise sur le cycle |
| Immédiat | La dérivation en cours est interrompue et remplacée | Plus réactif, risque de décrochage |
| Différé | La nouvelle grammaire attend un point de synchronisation | Le plus musical — transition propre |
La stratégie choisie : quantisé — comme TidalCycles, le changement ne prend effet qu’au début du prochain cycle. Pas de coupure au milieu d’une phrase, pas de décrochage. Les autres modes sont des options pour les performeurs qui veulent plus de contrôle.
État : ce qui persiste, ce qui se réinitialise
Un point délicat du hot-swap (remplacement à chaud) :
| Composant | Au hot-swap |
|---|---|
| Flags BP3 | Réinitialisés — la nouvelle grammaire repart de zéro |
| Sessions de code (SC, Python) | Persistent — les SynthDefs, les variables, les imports restent |
| Poids des règles | Réinitialisés — aux valeurs déclarées dans la nouvelle grammaire |
C’est une asymétrie à connaître : les flags sont dans BP3, qui recompile. Les sessions de code sont des sessions externes, qui continuent. Si un synthétiseur SuperCollider tourne depuis le début de la performance, il n’est pas interrompu par un changement de grammaire — seuls les nouveaux événements suivront les nouvelles règles.
L’analogie Session View
La Session View d’Ableton a libéré la musique du temps linéaire. Le musicien ne suit plus une ligne de temps — il lance des clips dans une grille, les combine, les empile.
BPscript fait un pas de plus : on ne lance pas des clips, on modifie des grammaires. Le clip est figé — il joue toujours la même chose. La grammaire est vivante — elle peut produire quelque chose de différent à chaque dérivation.
| Session View | BPscript |
|---|---|
| Lancer un clip | Activer un flag ([phase=2]) |
| Empiler des clips | Superposer des voix polymétriques ({A, B, C}) |
| Modifier un clip | Modifier une règle de grammaire |
| Muter une piste | Changer le routage JSON |
| Changer le tempo | Modifier @tempo: |
La différence fondamentale : dans Ableton, le contenu est fixe (chaque clip est un enregistrement). Dans BPscript, le contenu est généré (chaque dérivation produit potentiellement une variation unique).
Que peut-on modifier en live ?
Exemples concrets de modifications en cours de performance :
// Changer la densité d'une voix
rythme -> -!dha - -!ti -!dha // original
rythme -> -!dha -!ti -!dha -!ti // plus dense → recompile, effet au prochain cycle
// Changer un flag pour basculer de section
[phase=2] // directement dans l'éditeur
// Ajouter une voix polymétrique
S -> { melodie, rythme } // original
S -> { melodie, rythme, lumieres } // ajout de lumières → recompile
// Changer le type de dérivation (directive de bloc)
@mode:ord // original : ordonné
@mode:random // aléatoire → chaque cycle est différent
// Modifier un backtick
`sc: SynthDef(\grain, {...}).add` // changer le son sans toucher la structure
Chaque modification déclenche une recompilation. Le cycle entier (source modifié → nouvelle séquence → dispatch) prend moins de 100 ms.
Au-delà du navigateur
Aujourd’hui, le live coding BPscript fonctionne dans le navigateur : on modifie une scène .bps, elle se recompile et se redérive à chaud, et le son sort via Web Audio ou MIDI. C’est ce qui est démontrable.
Étendre ce live au-delà du navigateur — vers plusieurs runtimes (SuperCollider, Tidal…) pilotés depuis une même scène — est une direction de conception, pas encore réalisée.
Ce qu’il faut retenir
- 7 axes de modification indépendants : acteurs, composition, alphabet, tuning, tempérament, routage, backticks
- ~100 ms de latence pour un hot-swap typique — imperceptible
- Quantisé par défaut : le changement prend effet au prochain cycle (comme Tidal)
- Flags réinitialisés, sessions de code persistantes — asymétrie à connaître
- La grammaire est vivante : contrairement à un clip, chaque dérivation produit une variation unique
- Direction de conception : étendre le live au-delà du navigateur, vers plusieurs runtimes — pas encore réalisé
Glossaire
- Hot-swap : Remplacement à chaud — modifier le code pendant que le système tourne, sans l’arrêter
- Quantisation : alignement des changements sur une grille temporelle — le changement prend effet au prochain battement ou cycle
- Buffer : Tampon — les événements en cours continuent à jouer pendant que la nouvelle séquence se calcule
- Session View : Vue en grille d’Ableton Live où les clips sont lancés librement, sans ligne de temps
- Live coding : Pratique artistique de programmation en direct sur scène
Liens dans la série
- S1 — La vision — la filiation BP3 et le live coding
- S6 — Les flags — l’outil principal du performeur pour piloter la structure en live
- S9 — Les cinq couches — les axes de modification indépendants
- S10 — Le pipeline — ce qui se passe lors d’un hot-swap
Prérequis : S1 à S10 Temps de lecture : 10 min Tags : #BPscript #live-coding #hot-swap #performance
Prochain article : S12 — L’EBNF de BPscript : grammaire formelle du langage