Référençons ici les trucs/astuces et problèmes rencontrés lors de l'utilisation de Pure-data.

Lorsqu'on doit faire un logiciel d'une certaine ampleur, ou pour mieux se faire lire et se relire, le mieux c'est de respecter certaines conventions. Parcequ'on a pas tous la même idée de ce que c'est qu'un code clair. Pour Python, on a la fameuse PEP8, qui dit “préferez donc écrire votre code comme ceci ou comme cela, car c'est plus lisible vindedju”. Pour Puredata, on a des tentatives : https://puredata.info/docs/style-guide

Le $0, dans un objet, c'est une variable qui contient le numéro d'instance de l'abstraction qui contient cet objet.

[loadbang]
|
[i $0]
|
[print]

Par contre, dans un message, ça ne signifie rien (?), ça renvoie… 0. Lorsqu'on veut récupérer le numéro d'instance dans un message, on doit faire :

[bang(
|
[$0]
|
[$1(

Il y a quelques rares cas où on aimerait utiliser “$0” plutôt que le numero d'instance dans un message. On peut alors utiliser “$$0”. Un exemple, pour du patchage dynamique où l'on souhaite que l'argument d'un objet soit “$0” :

[;
mon-canvas obj 10 10 mon-objet~ $$0 (

Cependant, c'est une fausse solution : lorsqu'on redémarre le patch, puredata change tous les $$ en $\$ ! Y-a-t-il une raison à cela ? Mystère…

Une observation : c'est un problème de parsing. Ca relève de la mécanique interne, qui n'est pas vraiment documentée, plus que de la syntaxe, qui est normalement documentée et qui ne fait pas mention de $$. Le comportement attendu quand on utilise $0 est qu'il soit interprété, or ici on cherche à faire passer la chaîne de caractères $0: je ne sais pas si pd dispose d'une notation pour signifier cela (il me semble qu'il y a un moyen d'alimenter une boite type message avec un texte arbitraire, via set ou qqch dans ce goût là).

Je n'ai pas vérifié si le raisonnement est valide, mais l'approche que je choisirais pour contourner le problème, c'est de ne pas chercher à copier la chaîne “$0” via un message, donc d'abandonner l'idée, car on en n'a pas forcément besoin. Par contre, on pourra quand même utiliser “$0” dans l'instance maître (celle qui génère les autres patchs), et étant donné qu'on contrôle le nom de chaque objet au sein de cette instance maître, on a moins besoin d'utiliser $0 dans les sous-patchs pour éviter les collisions. On peut en effet mettre des noms à rallonge pour nos objets généres, pour les arrays, etc. Par exemple, on peut utiliser un compteur pour nommer ses objets générés (tout en transmettant la valeur du $0 acquise depuis le patch maître) : ce n'est pas gênant.

Le cas de figure où $0 est utile, c'est lorsqu'on charge deux fois le même patch depuis le menu de PD (c'est d'ailleurs le moment où la valeur de $0 est fixée), ou bien lorsqu'on utilise des noms de variable trop génériques et qu'on se dit qu'un autre programmeur d'un autre patch qu'on souhaite charger aura peut-être utilisé les mêmes.

Lorsqu'on souhaite avoir un nombre indéterminé de sorties dans une abstraction, on peut créer des outlets dynamiquement à la création de l'objet avec un [loadbang]. Seulement, lorsqu'on ré-ouvre le patch, les objets statiques et leurs connexions sont créés avant les objets créés dynamiquement, donc les connexions entre les deux foirent. Comment contourner ce problème ?

Apparemment, il n'y a pas de solution à la vanille lorsqu'on veut maitriser le processus d'initalisation de puredata. Il faut utiliser [initbang] disponible dans la bibliothèque iemguts. [initbang] envoie son bang AVANT l'initialisation du patch (j'entends par là, la création des objets contenus dans le patch et leurs connexions). Donc, lorsqu'on a des objets dynamiques, cet [initbang] devient plus qu'utile.

Une réponse quand même : pas besoin d'utiliser les câbles (qui ont un rôle visuel afin de pouvoir les manipuler à la main) lorsque ce qui t'intéresse est en fait d'avoir un truc automatisé. Tu dois pouvoir transmettre les données avec des [send], [throw~] & co.