S11) En live

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 recompile le source modifié → nouvelle grammaire BP3 (~10 ms)
Le moteur BP3 dérive la nouvelle grammaire → nouvelle séquence de timed tokens (~50-100 ms pour une grammaire typique)
Le runtime aval (hors dépôt — dispatcher, transports) commence à router les nouveaux événements
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.

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 : le dépôt couvre la compilation et la dérivation BP3/WASM (sortie = timed tokens). Le dispatcher, les transports et les sessions de code sont le consommateur aval des timed tokens — leur implémentation vit hors du dépôt. 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

← Retour à l’index