S14) Sons, specs et effets
Comment BPscript paramètre le son sans inventer un langage de patching
Le runtime sait câbler un filtre. BPscript sait quand le filtre doit s’ouvrir. Chacun fait ce qu’il sait faire — et la polymétrie les synchronise.
Où se situe cet article ?
Après les acteurs (S3) et le temps (S5), on comprend comment le son est paramétré. Pas comment il est produit (c’est le boulot du runtime) — comment BPscript lui dit quoi faire et quand.
Trois échelles temporelles
Chaque terminal dans la grammaire traverse trois couches de paramètres, de la plus permanente à la plus éphémère :
Spec — les propriétés du son
La spec (specification) définit les propriétés permanentes d’un terminal : timbre, échantillon, caractéristiques acoustiques. Résolue une seule fois, elle ne change pas pendant la pièce.
@actor sitar alphabet:sargam scale:sargam_22shruti sounds:sitar_timbre transport:webaudio
Le fichier sounds:sitar_timbre contient les specs par terminal :
{
"sa": { "wave": "sawtooth", "decay": 2000, "brightness": 0.7 },
"re": { "wave": "sawtooth", "decay": 1800, "brightness": 0.6 },
"dha": { "type": "percussion", "sample": "tabla_dha.wav", "decay": 300 }
}
CT — les surcharges ponctuelles
Les CT (Control Table) sont les qualificateurs () runtime (S3). Ils changent un paramètre ponctuellement — la nouvelle valeur persiste jusqu’au prochain () qui la remplace.
Sa(vel:120) // vélocité 120 pour cette note
{A B C}(vel:80, pan:0.3) // vélocité 80 et pan gauche pour le groupe
CV — la modulation continue
Les CV (Control Voltage) sont des objets temporels qui modifient un paramètre sur une durée : enveloppes ADSR, LFO, ramps (S3). Un CV se déclare avec une cible et un transport, puis se place dans la grammaire comme n’importe quel objet temporel :
env1(Phrase1, webaudio) = filter.adsr(10, 200, 0.5, 300)
// │ │ │ │
// │ │ │ └─ paramètres (attack, decay, sustain, release)
// │ │ └─ type d'objet dans la lib
// │ └─ transport (sortie)
// └─ cible (entrée : terminal, séquence, sous-grammaire, scène)
S -> { Phrase1 , env1 } // env1 module la cible pendant sa durée
Cascade — la priorité
Les trois couches se combinent avec une cascade (priorité croissante) inspirée de CSS :
spec < CT < CV
(le plus permanent) → (le plus ponctuel)
Un CV surcharge un CT, qui surcharge une spec. Si un paramètre n’est pas défini dans une couche, la couche inférieure s’applique.
Exemple : un Sa avec spec.vel=80, CT.vel=120, et un CV env(vel: ramp(40,127)) → le CV gagne pendant sa durée, puis le CT reprend.
Effets : le runtime câble, BPscript paramètre
BPscript n’a pas de langage de patching. Pas de concept de bus, de chaîne, de >. Zéro mot réservé en plus.
La séparation est nette :
| Couche | Responsabilité | Exemple |
|---|---|---|
| Runtime (backtick init) | Câblage du graphe audio | sitar → lpf → reverb → out |
| BPscript (grammaire) | Quand et comment les paramètres changent | lpf.cutoff via polymétrie |
| BP3 (moteur) | Calcul des durées et synchronisation | polymétrie mélodie + courbe de filtre |
Étape 1 — Le runtime définit le graphe
Le câblage est dans le runtime. C’est lui qui sait faire ça nativement :
`js:
const lpf = ctx.createBiquadFilter();
lpf.type = 'lowpass';
lpf.frequency.value = 1000;
sitar.connect(lpf).connect(ctx.destination);
`
Étape 2 — BPscript pilote les paramètres dans le temps
Les paramètres des effets sont placés en polymétrie — comme une voix parallèle à la mélodie. BP3 calcule la synchronisation :
S -> { melodie , sitar.lpf.cutoff(ramp(200, 4000)) }
La mélodie joue dans une voix, la courbe de filtre dans une autre. BP3 les synchronise. Le résultat : le filtre s’ouvre progressivement pendant que la mélodie se déroule.
Pourquoi pas de patching ?
Chaque runtime a son propre système de câblage (SuperCollider : SynthDefs + Bus, WebAudio : AudioNode.connect, Max : objets + câbles). Inventer un DSL (Domain-Specific Language) de patching dans BPscript :
- Dupliquerait les capacités de chaque runtime — en moins bien
- Limiterait les possibilités aux constructions prévues par BPscript
- Ajouterait de la complexité syntaxique pour un gain douteux
Les backticks suffisent pour le câblage (c’est du ponctuel, pas du temps). La polymétrie suffit pour le pilotage dans le temps (c’est ce que BP3 sait faire). Ensemble, ils couvrent les cas pratiques sans un seul mot en plus.
Ce qu’il faut retenir
- Trois échelles : spec (permanent), CT (ponctuel
()), CV (continu sur une durée) - Cascade :
spec < CT < CV— la couche la plus spécifique gagne - Le runtime câble (backtick init), BPscript paramètre dans le temps (polymétrie + CV)
- Pas de patching — les effets sont pilotés avec les mécanismes existants, zéro mot en plus
- La polymétrie synchronise mélodie et paramètres d’effets — c’est le même moteur
Glossaire
- Spec : Propriétés permanentes d’un terminal (timbre, sample, déclin) — résolues une fois au chargement
- CT (Control Table) : Surcharge ponctuelle via
()— persiste jusqu’au prochain() - CV (Control Voltage) : Modulation continue sur une durée (ADSR, LFO, ramp) — déclarée
nom(cible, transport) = lib.type(args) - Cascade : Système de priorité entre couches — la couche la plus spécifique surcharge les autres
- Patching : Câblage des modules audio (filtre → reverb → sortie) — géré par le runtime, pas par BPscript
Liens dans la série
- S3 — Types, acteurs et rattachements — où les sounds sont déclarés
- S5 — Polymétrie — comment les effets sont synchronisés avec la musique
- S9 — Le système de hauteurs — la couche pitch vs la couche sons
- S10 — Le dispatcher — comment spec/CT/CV sont résolus au runtime
Prérequis : S3, S5
Temps de lecture : 10 min
Tags : #BPscript #sons #effets #CV #cascade
Prochain article : S15 (à venir) — La transposition au-delà du tempérament égal