Most recent edit on 2007-07-05 18:56:37 by SuperCollider
Additions:
Pour rester au plus près du fonctionnement réel de sc (dialogue par OSC), JmC préconise l'utilisation du "messaging style" dans la syntaxe du client:
Soit un SynthDef:
L'envoi de message peut être différé, en utilisant le message .sendBundle : le premier argument de sendBundle est un temps "logique", sc écrit un timestamp dans le message osc destiné au serveur
voir gestion du temps: Temps logique, temps physique
Deletions:
Pour rester au plus près du fonctionnement réel de sc (dialogue par OSC), JmC préconise l'utilisation du "messaging style" dans la syntaxe du client:
Soit un SynthDef:
L'envoi de message peut être différé, en utilisant le message .sendBundle : le premier argument de sendBundle est un temps "logique", sc écrit un timestamp dans le message osc destiné au serveur
voir gestion du temps: TempsLogiqueTempsPhysique
Edited on 2007-07-04 18:40:49 by SuperCollider
Additions:
SynthDefs < Index > Ordre d'exécution
Messages
voir gestion du temps: TempsLogiqueTempsPhysique
SynthDefs < Index > Ordre d'exécution
Deletions:
voir gestion du temps: TempsLogiqueTempsPhysique
Edited on 2007-05-30 15:53:34 by SuperCollider
Additions:
voir gestion du temps: TempsLogiqueTempsPhysique
Deletions:
[voir gestion du temps: logical time, physical time]
Edited on 2007-05-30 11:10:52 by SuperCollider
Additions:
On envoie au serveur des messages pour la création et le paramétrage des synths: voir Server-Command-Reference∞
on peut envoyer des messages par la suite au serveur pour changer ces valeurs, à l'aide du message \n_set:
Deletions:
On envoie au serveur des messages pour la création et le paramétrage des synths: voir Server-Command-Reference
on peut envoyer des messages par la suite au serveur pour changer ces valeurs:
Edited on 2007-05-29 23:30:38 by SuperCollider
Additions:
Pour rester au plus près du fonctionnement réel de sc (dialogue par OSC), JmC préconise l'utilisation du "messaging style" dans la syntaxe du client:
- Vous êtes responsable de l'ordre d'exécution des synths, de leur destruction.
- Un index étant par nécessité unique, vous êtes aussi responsable de la bonne gestion des id lors de l'envoi au serveur.
L'envoi de message peut être différé, en utilisant le message .sendBundle : le premier argument de sendBundle est un temps "logique", sc écrit un timestamp dans le message osc destiné au serveur
Deletions:
Pour rester au plus près du fonctionnement réel de sc (dialogue par OSC), JmC préconise l'utilisation du "messaging style" dans la syntaxe du client:
- Vous êtes responsable de l'ordre d'exécution des synth, de leur destruction.
- Un index étant par nécéssité unique, vous êtes aussi responsable de la bonne gestion des id lors de l'envoi au serveur.
L'envoi de message peut être différé, en utilisant le message .sendBundle : le premier argument de sendBundle est un temps "logique", sc écrit un timestamp dans le message osc destiné au serveur
Edited on 2007-05-29 23:27:42 by SuperCollider
Additions:
- le message \s_new invoque la création d'un synth
- \test est le nom du synthdef à utiliser
- 1000 est l'index du synth sur le serveur
Deletions:
- le message \s_new invoque la création d'un synth
\test est le nom du synthdef à utiliser
1000 est l'index du synth sur le serveur
Oldest known version of this page was edited on 2007-05-29 23:26:23 by SuperCollider []
Page view:
Pour rester au plus près du fonctionnement réel de sc (dialogue par OSC),
JmC préconise l'utilisation du "messaging style" dans la syntaxe du client:
Soit un
SynthDef:
s.boot;
SynthDef(\test, { | freq = 400, mul = 0.1|
Out.ar(0, SinOsc.ar(freq, 0, mul))!2
}).send(s)
On envoie au serveur des messages pour la création et le paramétrage des synths: voir Server-Command-Reference
s.sendMsg(\s_new, \test, 1000);
- le message \s_new invoque la création d'un synth
- \test est le nom du synthdef à utiliser
- 1000 est l'index du synth sur le serveur
- Ce type de passage de message nécessite beaucoup de rigueur dans la programmation.
- Vous êtes responsable de l'ordre d'exécution des synth, de leur destruction.
- Un index étant par nécéssité unique, vous êtes aussi responsable de la bonne gestion des id lors de l'envoi au serveur.
Par exemple, réévaluer tel quel la ligne s_new ci-dessus provoque une erreur:
FAILURE s_new duplicate node ID
on peut générer automatiquement un id unique en utilisant la méthode nextNodeID:
(
i = s.nextNodeID;
s.sendMsg(\s_new, \test, i);
)
//une alternative consiste à mettre -1 en tant que ID:
s.sendMsg(\s_new, \test, -1);
Gestion des paramètres
le synthdef
\test possède deux arguments,
freq, et
mul, dotés de valeurs par défaut. On peut donner d'autres valeurs (statiques) lors de la création du synth:
i = s.nextNodeID;
s.sendMsg(\s_new, \test, i, 0, 0, \freq, 800, \mul, 0.4);
//on peut envoyer des messages par la suite au serveur pour changer ces valeurs:
s.sendMsg(\n_set, i, \freq, 100);
s.sendMsg(\n_set, i, \freq, 400, \mul, 0.2 );
L'envoi de message peut être différé, en utilisant le message .sendBundle : le premier argument de sendBundle est un temps "logique", sc écrit un timestamp dans le message osc destiné au serveur
(
s.sendBundle(0.2, //temps
["/s_new", "test", x = s.nextNodeID, 1, 1, "freq", 800],
["/s_new", "test", y = s.nextNodeID, 1, 1, "freq", 1001],
["/s_new", "test", z = s.nextNodeID, 1, 1, "freq", 1202]
);
s.sendBundle(1.2, ["/n_free", x],["/n_free", y],["/n_free", z]);
)
(
SynthDef(\test2, {|freq = 200, mul = 0.1|
Out.ar(0, Formant.ar(freq, freq * Rand(1, 3.0), freq * Rand(1, 3.0))!2 * EnvGen.kr(Env.perc(releaseTime: 0.02), doneAction: 2) * mul)
}).send(s)
)
Routine({
inf.do {0.1.wait;
s.sendMsg(\s_new, \test2, s.nextNodeID.postln, 1, 1, \freq, exprand(100, 1000), \mul, 0.2.rand)
}
}).play
[voir gestion du temps: logical time, physical time]