Me suis renseigné un peu sur les possibilités de patching dynamique avec pd. J'ai fait un truc minimal:
receiver.pd accepte une connection en udp sur puis route les messages(protocole basique de pd : FUDI), seulement 3 types de messages pour l'instant:
“open <nom_abstraction> <numero>;” : on ne doit pas écrire le .pd dans nom_abstraction et l'abstraction doit se trouver dans le répertoire courant le numéro est décidé par le client qui se connecte à pd, à lui de gérer.. receiver ouvre une instance de wrapper.pd qui lui donne son $0 via une variable globale, ce qui permet à receiver de mapper le numéro du client avec le numéro du canvas effectif de l'objet. receiver ordonne ensuite via une variable(-$0) du wrapper nouvellement créé d'éxecuter la creation de 2 patchs, sound et env. Seul sound est util pour le moment, faire un essai pour voir le contenu. grâce au line~, le son ne “clic” pas au chargement.
“close <numero>;” : on tue le wrapper contenant l'abstraction après avoir utilisé le line~ pour ne pas le tuer brutalement. remarque : attention pour l'instant c'est brute, le temps d'ouverture et de fermeture du volume (pour line) est codé en dur dans le code de création du sous-patch wrappant l'abstraction et lorsque qu'on kill une abstraction il faut avoir attendu suffisament longtemps pour le line, cette attente est gérée par un bête delay dont la valeur est aussi codée en dur!
“tell <numero> <nom_variable> <valeur>;” : le numéro permet de récupérer le numéro de canvas du wrapper, qui a lui meme passer ce numéro comme argument à la création de l'objet wrappé. on a un exemple avec simpleosc.pd. Cette abstraction contient une variable $1-freq…
on peut utiliser sounds_backend.ml de façon interactive pour voir comment ça marche. Ou “netcat -u localhost 3005”…
j'utilise pd-extended 0.43.4, les libs pdcontainer(pour h_map), iemnuts(pas encore mais surement besoin pour les enveloppes).
Bon, clairement ça parait brutal d'utiliser pd comme ça, non? Pour la gestion des enveloppes/effets ça risque d'être assez compliqué mais y'a clairement des possibilités.
j'attends des critiques.
Comment faire une gestion de groupes/effets? Galère mais faisable avec pidi. Débuts de patchs sur git.
L'idée pour les effets c'est une gestion de liste avec des send13~/receive13~ (de la lib ext13)
receive13~ inleft receive13~ inright
\ /
\ /
\ /
\ /
\ /
\ /
\ /
[ EFFET ]
/ \
s13~ outleft s13~ outright
Comme ça ça permet d'ajouter un effet en queue de liste, et de supprimer un effet n'importe ou dans la liste en connaissant son nom. ça demande cependant une gestion importante de variables, quelles sont les entrées/sorties actives des maillons précédent et suivant, c'est pas fait…
Go SuperCollider pasque c'est cool.
* voir lib quarks redSampler pour lecture fichiers son.