Sons, specs et effets · roomi fields

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 contrôles non-temporels

Les qualificateurs () runtime (S3) gouvernent le contenu. Ils viennent en deux régimes :

contenance (...) : s’applique à toute sa portée (la règle ou le groupe), y compris les notes écrites avant, et s’arrête à son bord (confinée) ;
flux !(...) : coule vers l’avant dans l’ordre joué, traverse les bords, jusqu’au prochain contrôle (comportement hérité de BP3).

Sa(vel:120)                       // override d'une note
Bass -> C2 E2 G2 (wave:sawtooth)  // contenance : les trois notes, confiné à Bass
S -> A !(vel:100) B               // flux : à partir d'ici, vélocité 100 vers l'avant

Priorité, du plus fort au plus faible : override de note > flux > contenance > défauts. Ces contrôles sont résolus une fois par terminal en amont (par le moteur) ; le dispatcher les lit, il ne les recalcule pas.

CV — la modulation continue

Les CV (Control Voltage) sont le troisième type temporel : enveloppes ADSR, oscillateurs lents (LFO), rampes (S3). On déclare un CV de façon descriptive — un nom lié à un modulateur de la librairie mod —, puis on le branche par note sur une entrée :

cv env1 : mod.adsr(attack:10, decay:200, sustain:0.5, release:300)

Bass -> C2 C2 C3 (cutoff: env1)   // env1 module la coupure de chaque note

Le modulateur produit une valeur normalisée entre 0 et 1, que Kanopi mappe sur la plage physique de l’entrée choisie. Cinq entrées sont reconnues :

Entrée	Agit sur	Mappage du 0–1
cutoff	fréquence de coupure	exponentiel (≈20 Hz → 20 kHz)
amplitude	gain	linéaire
resonance	facteur Q	linéaire (0 → 30)
pitch	désaccord	±1200 cents
pan	panoramique	−1 → 1

La cible d’un branchement peut être un symbole dérivable — une voix sœur que la grammaire résout —, ce qui permet à une voix d’en moduler une autre sans re-dérivation. Le CV reçoit sa durée de la grammaire.

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 branché sur l’amplitude → le CV gagne pendant sa durée, puis le CT reprend.

Cette cascade à trois strates est la couche runtime. Le timbre lui-même (la spec d’un son) se résout à travers une cascade plus profonde — défaut moteur → défauts de scène → alphabet → acteur → inline — fusionnée propriété par propriété, là encore à la manière de CSS.

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
Contenance (...) / Flux !(...) : deux régimes de contrôle non-temporel — contenance confinée à sa portée, flux filant vers l’avant ; priorité override > flux > contenance > défauts
CV (Control Voltage) : Modulation continue sur une durée (ADSR, LFO, ramp) — déclarée cv nom : mod.type(args), branchée par note (entrée: nom), valeur 0–1 mappée par l’entrée
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 — La transposition au-delà du tempérament égal

← Retour à l’index