Il existe plusieurs façons d'organiser ses patchs. Nous présentons ceux rencontrés fréquemment.
Lors de la rédaction d'un patch, il arrive souvent que la taille d'une seule fenêtre ne soit plus adaptée à la complexité du projet. Pour séparer les parties d'un système plus complexe, on peut dès lors créer des sous-patchs. Ce sont des boîtes ressemblant à des objets, mais qui contiennent une portion du patch qui s'ouvre dans une autre fenêtre (pensez aux poupées russes qui s'emboîtent les unes dans les autres). Le sous-patch appartient entièrement au patch principal. Le patch principal pourra être déplacé (dans un autre répertoire, partagé en ligne). Le ou les sous-patchs intégrés au patch principal seront également déplacés ou partagé en même temps (contrairement à l'abstraction).
Pour créer un sous-patch, il suffit de créer une boîte "object" dans laquelle on écrit : [pd nomdusous-patch].
Dans le sous-patch, si l'on veut créer des entrées et des sorties pour les données, il faut insérer des objets [inlet] et [outlet]. Pour faire transiter le son, on utilise les objets [inlet~] et [outlet~]. Il est également possible d'utiliser les messages sans ficelles. Il faudra alors prêter une attention particulière à la notion de variables globales et locales. Reportez-vous au chapitre « Flot des données » pour de plus amples informations à ce sujet.
Il est à noter que s'il est possible de dupliquer des sous-patchs, les modifications effectuées dans l'un ne se répercuteront pas dans les autres. Conséquence directe : les sous-patchs de même nom peuvent avoir des contenus différents. Par souci de clarté, il est alors recommandé de nommer différemment les sous-patchs au contenu différent.
Si un sous-patch est amené à être utilisé à l'identique plusieurs fois dans le même patch, il peut être souhaitable de créer une abstraction pour faciliter d'éventuelles modifications ultérieures.
Les abstractions sont des patchs prévus pour être réutilisés comme raccourcis de programmation. Pratiquement identiques à une boîte objet (fonctions), on peut en revanche les « ouvrir », à la différence des objets natifs de Pure Data. En mode action, un clic de souris sur une abstraction suffit pour voir ce qu'elle contient.
Nous pouvons donc écrire nos propres abstractions. Ces abstractions sont ensuite appelées comme des objets ordinaires depuis le patch principal nommé aussi « patch maître ». À la différence d'un sous-patch, lorsqu'on partage ou déplace le patch principal dans un autre répertoire, on doit réitérer l'opération pour les abstractions qui lui sont attachées. Sinon, on obtient le même résultat que pour un objet qui refuse de « naître », c'est-à-dire des pointillés rouges entourant le nom de l'abstraction (objets non reconnus).
Pour simplifier l'écriture d'un projet, l'abstraction peut être soit sauvegardée dans un dossier spécifié de la configuration des chemins « regardés par Pure data » ou, à défaut, dans le même dossier que le « patch maître » qui appelle cette abstraction. Pour configurer les chemins, allez dans le menu "File", sélectionnez "Path", puis ajoutez le chemin où se trouve l'abstraction désirée (voir la section « Configuration des chemins »).
Une abstraction est donc indépendante du « patch maître » et peut être facilement réutilisée d'un projet à l'autre.
L'un des intérêts de l'abstraction réside dans le fait que toute modification effectuée dans l'une d'entre elles se répercutera, une fois l'abstraction sauvegardée, dans toutes les autres présentes dans le patch.
Il y a une erreur de communication avec le serveur Booktype. Nous ne savons pas actuellement où est le problème.
Vous devriez rafraîchir la page.