S11) Live
Modifying while it plays
Hot-swap, latency, granularity
Most tools play music written in advance. With BPscript, music is derived in real-time according to rules — and these rules can be modified while it plays.
Where does this article fit in?
This is the summary article: after seeing the language (S2–S8), the layers (S9), and the architecture (S10), we assemble everything for live performance. How does it work on stage?
Seven independent axes of modification
Live coding with BPscript means modifying one or more aspects of the scene while the music is playing. Each layer is independently modifiable:
| What is modified | What changes | What remains |
|---|---|---|
The actors (@actor) |
Alphabet/tuning/transport attachments | The structure |
| The composition (rules, flags) | Temporal structure | Attachments |
| The alphabet (JSON) | Note names | Frequencies |
| The tuning (JSON) | Tuning/Intonation | Note names |
| The temperament (JSON) | Interval grid | The scale |
| The routing (JSON) | Destination | The music |
| The backticks (code) | Algorithmic logic | The structure |
It’s the same piece, seven ways to transform it live. Changing the tuning from shruti 22 (Indian intonation) to 12-TET is a single JSON file — the grammar doesn’t move, only the frequencies change (S9).
What happens when you modify
When the composer modifies the .bps file live:
- The compiler recompiles the modified source → new BP3 grammar (~10 ms)
- The BP3 engine derives the new grammar → new sequence of timed tokens (~50-100 ms for a typical grammar)
- The downstream runtime (outside the repository — dispatcher, transports) begins routing the new events
- The code sessions continue — their variables and imports are preserved
Total time: 50-100 ms for a typical grammar. A human does not perceive a structural change of less than 100 ms — it’s transparent.
For deep grammars (recursive polymetries, numerous alternatives), derivation can take longer. In this case, the system uses a buffer: events from the previous sequence continue to play while the new sequence is being calculated.
Scope: the repository covers BP3/WASM compilation and derivation (output = timed tokens). The dispatcher, transports, and code sessions are the downstream consumer of the timed tokens — their implementation lives outside the repository. This article describes the complete system.
Granularity: when does the change take effect?
Three possible strategies:
| Strategy | Behavior | Analogy |
|---|---|---|
| Quantized | The change takes effect at the next derivation cycle | Like TidalCycles which quantizes on the cycle |
| Immediate | The current derivation is interrupted and replaced | More reactive, risk of glitching |
| Deferred | The new grammar waits for a synchronization point | The most musical — clean transition |
The chosen strategy: quantized — like TidalCycles, the change only takes effect at the start of the next cycle. No cutting in the middle of a phrase, no stalling. The other modes are options for performers who want more control.
State: what persists, what resets
A delicate point of hot-swapping:
| Component | Upon hot-swap |
|---|---|
| BP3 Flags | Reset — the new grammar starts from scratch |
| Code sessions (SC, Python) | Persist — SynthDefs, variables, and imports remain |
| Rule weights | Reset — to the values declared in the new grammar |
This is an asymmetry to be aware of: flags are within BP3, which recompiles. Code sessions are external sessions, which continue. If a SuperCollider synthesizer has been running since the start of the performance, it is not interrupted by a grammar change — only new events will follow the new rules.
The Session View analogy
Ableton’s Session View freed music from linear time. The musician no longer follows a timeline — they launch clips in a grid, combine them, stack them.
BPscript goes one step further: you don’t launch clips, you modify grammars. A clip is frozen — it always plays the same thing. A grammar is alive — it can produce something different with each derivation.
| Session View | BPscript |
|---|---|
| Launching a clip | Activating a flag ([phase=2]) |
| Stacking clips | Layering polymetric voices ({A, B, C}) |
| Modifying a clip | Modifying a grammar rule |
| Muting a track | Changing the JSON routing |
| Changing the tempo | Modifying @tempo: |
The fundamental difference: in Ableton, the content is fixed (each clip is a recording). In BPscript, the content is generated (each derivation potentially produces a unique variation).
What can be modified live?
Concrete examples of modifications during a performance:
// Change the density of a voice
rythme -> -!dha - -!ti -!dha // original
rythme -> -!dha -!ti -!dha -!ti // denser → recompile, effect at next cycle
// Change a flag to switch sections
[phase=2] // directly in the editor
// Add a polymetric voice
S -> { melodie, rythme } // original
S -> { melodie, rythme, lumieres } // adding lights → recompile
// Change the derivation type (block directive)
@mode:ord // original: ordered
@mode:random // random → each cycle is different
// Modify a backtick
`sc: SynthDef(\grain, {...}).add` // change the sound without touching the structure
Every modification triggers a recompilation. The entire cycle (modified source → new sequence → dispatch) takes less than 100 ms.
Beyond the browser
Today, BPscript live coding works in the browser: you modify a .bps scene, it recompiles and re-derives on the fly, and the sound comes out via Web Audio or MIDI. This is what is demonstrable.
Extending this live performance beyond the browser — toward multiple runtimes (SuperCollider, Tidal…) controlled from the same scene — is a design direction, not yet realized.
Key takeaways
- 7 independent axes of modification: actors, composition, alphabet, tuning, temperament, routing, backticks
- ~100 ms of latency for a typical hot-swap — imperceptible
- Quantized by default: the change takes effect at the next cycle (like Tidal)
- Flags reset, code sessions persist — an asymmetry to be aware of
- The grammar is alive: unlike a clip, each derivation produces a unique variation
- Design direction: extending live performance beyond the browser to multiple runtimes — not yet realized
Glossary
- Hot-swap: Hot-swapping — modifying code while the system is running, without stopping it
- Quantization: aligning changes to a time grid — the change takes effect at the next beat or cycle
- Buffer: current events continue to play while the new sequence is being calculated
- Session View: Ableton Live’s grid view where clips are launched freely, without a timeline
- Live coding: Artistic practice of programming live on stage
Links in the series
- S1 — The vision — BP3 lineage and live coding
- S6 — Flags — the performer’s main tool for controlling structure live
- S9 — The five layers — independent axes of modification
- S10 — The pipeline — what happens during a hot-swap
Prerequisites: S1 to S10
Reading time: 10 min
Tags: #BPscript #live-coding #hot-swap #performance
Next article: S12 — BPscript EBNF: formal grammar of the language