Pure-Data - Savoir-faire

Pour télécharger un patch, clic droit sur l'image et choisir "Enregistrer la cible sous...".

Loadbang

L'objet "loadbang" permet d'envoyer automatiquement un message "bang" à l'ouverture d'un patch. Il n'a ni entrée ni argument.

Automatisation

Dans cet exemple très simple, au démarrage du fichier, un métronome est lancé (objet "metro") qui bat toutes les 2 secondes (2000 millisecondes). Pour les débutants en PD : le rond est un bang graphique et l'objet "print" envoie un message "truc" dans la fenêtre de texte.

Loadbang est indispensable dès lors qu'un patch doit tourner automatiquement.

Multiples loadbang : inconvénients possibles

Cependant, il arrive couramment que des dysfonctionnement apparaissent dans un patch lorsque plusieurs loadbang simultanés sont mis en place.

En effet :

- Certains événements doivent être initialisés avant que d'autres ne soient lancés.
Par exemple, il faut activer l'audio (Media/Audio On ou message dsp 1) avant de lancer la lecture d'un fichier son. Il faut envoyer les paramètres de la fenêtre Gem au gemwin avant le message "create".

- Certains événement ne peuvent matériellement s'exécuter simultanément.
Par exemple, si un loadbang active simultanément plusieurs messages open pour de gros fichiers sons ou video, certains ne pourront être ouverts.

En cas de problème grave au démarrage (plantage systématique, sur-utilisation des ressources, etc), il peut être nécessaire d'empêcher le loadbang de fonctionner. Pour cela, il faut ouvrir PD avec le paramètre -noloadbang. Ce paramètre s'ajoute dans le fichier de configuration de démarrage de PD (pd.bat en PC).

Suggestion de solutions

a) Un seul loadbang, un sous-patch de démarrage

-> Utiliser un seul objet loadbang pour tous les paramètres à initialiser et créer un sous-patch spécifique pour cette étape.

Cela permet de ne pas oublier un loadbang perdu quelque part dans un autre sous-patch et pouvant poser problème. Le loadbang est alors envoyé à ses diverses destinations par l'intermédiaire des objets send/receive. Il vaut mieux utiliser des noms évidents pour ces send/receive.

On peut bien sûr préférer :

le principe étant que la procédure de démarrage soit la plus intuitive et évidente possible pour le patcheur et/ou le débuggueur.

b) Le trigger bang bang

-> Ordonner les événements de façon à ce que chaque étape soit lancée dans le bon ordre.

L'objet "trigger" possède une entrée et autant de sorties que nécessaires, précisées dans la séquence de lettre qui suit le "t". Les arguments peuvent être un bang (b), un nombre (f), un symbole (s), une liste (l) ou n'importe quoi arrivé en entrée (a).

Dans le cas d'un loadbang en entrée, les arguments du trigger sont des bang, autant qu'il y a d'étapes à ordonner ("t b b b" pour trois étapes, "t b b b b b" pour 5, ...)

Les sorties du trigger sont ordonnées de la droite vers la gauche. Dans cet exemple, les paramètres de la fenêtre Gem (gemwin) sont d'abord réinitialisés (reset). Ensuite un message précise que la fenêtre ne doit pas avoir de bord et être de dimensions 700 x 700 pixels. La fenêtre est ensuite créée (message create) puis l'affichage est lancé (message 1).

c) Délais

Enfin, il est indispensable parfois d'utiliser l'objet "delay" pour laisser un temps minimum nécessaire à certaines étapes pour s'effectuer.

L'objet delay provoque une attente de la durée donnée dans l'argument ou dans l'entrée de droite.

Dans cet exemple, un ordre de démarrage est tout d'abord lancé à initstatus (le receive est dans un sous-patch qui corrige le souci du running status en Midi). Ensuite un message 1 est envoyé sur initspi au bout de 0,2 secondes, puis initreposx est activé (deux paramètres qu'il faut initialiser). Enfin une fenêtre GEM est créée au bout de 500 ms par l'intermédiaire d'un trigger.