La programmation visuelle tend à créer des structures extrêmement complexes qui peuvent dans un premier temps s’avérer très jolies, mais qui, dès lors que vous travaillez sur un projet tant soit peu sérieux, devront être modularisées grâce à des sous-patches. |
Un patch et son sous-patch (sous forme de node et InABox )
|
Le terme sous-patch correspond à un patch faisant office de node à l’intérieur d’un autre patch. Il s’agit alors d’une question de point de vue : en fait, chaque sous-patch est un patch ordinaire que l’on appelle sous-patch lorsqu’il est considéré du point de vue du patch dans lequel il se trouve. De la même manière, un patch peut être considéré comme un patch parent lorsque l’on se réfère au patch contenant la node en question. Par exemple : Patch1 contient Patch2.
Du point de vue de Patch1: Patch2 est un sous-patch Du point de vue de Patch2: Patch1 est son patch-parent En d’autres termes : un patch peut contenir une multitude de sous-patches, mais chaque patch n’a qu’un patch parent. |
Arborescence de sous-patches en cascade vus dans le Finder window
|
Selon cette définition, chaque patch que vous voyez est également représenté par une node dans un autre patch, formant ainsi toute une hiérarchie. Tout en haut de celle-ci, on trouve le Root, que l’on peut ouvrir à tout moment avec le raccourci ALT+R. |
Vous comprendrez peut-être plus facilement en sachant que les sous-patches ne sont qu’un moyen visuel pour l’utilisateur de structurer ses données. Pour vvvv, cela ne change rien si vous mettez toutes vos nodes dans le même (très gros) patch ou si vous structurez votre projet proprement pour le rendre lisible. Apprendre quand il est nécessaire de modulariser (c’est-à-dire, à quel moment il est nécessaire d’employer des sous-patches) est un des plus gros points de l’apprentissage de l’art de la programmation visuelle. Si vous avez besoin de quelques conseils, lisez la page Software Engineering Patterns with vvvv. |
FinderPour avoir un apperçu de toutes les nodes d’un patch, voire même de toute la hiérarchie de votre projet, ouvrez le Finder ou faites CTRL + TAB pour passer en revue toutes les fenêtres ouvertes. |
Visibilité des pinsLa visibilité d’une pin peut être changée par l’utilisateur via l’Inspektor. Vous pouvez donc définir la visibilité des pins de votre sous patch en changeant la propriété Pin Visibility de l’IOBox pour la valeur désirée. |
Détecter si une entrée a changéChaque IOBox dispose d’une pin cachée Changed qui peut être utilisée pour détecter si une entrée a changé. Vous devez l’activer en changeant sa visibilité via l’Inspektor. Vous pouvez par exemple l’utiliser pour qu’un sous-patch n’ait à calculer ses résultats que si l’entrée a changée. Ou bien, créez un pin d’entrée Enabled pour laisser l’utilisateur de votre sous-patch contrôler son exécution. |
Gérer des BinSizeSi vous voulez qu’une des entrées de votre sous-patch dispose d’une pin BinSize, prenez soin d’utiliser une node NormalizeBinsize (disponible dans de nombreuses catégories). Elle simplifie l’utilisation des Bins et BinSizes dans un sous-patch dans le fait qu’elle convertit des BinSizes (positifs ou négatifs) en Bins que vous pourrez utiliser dans vos calculs. |
Vous pouvez créer une instance d’un sous-patch comme n’importe-quelle autre node grâce au NodeBrowser. Tapez « t » (soit t suivi d’un espace) pour ne filtrer que les sous patch présents dans le dossier du patch actuel. Plusieurs instances d’un sous-patch peuvent cohabiter dans la joie et calculer leurs propres données. Mais soyez attentif au fait que si vous changez quoi que ce soit à l’intérieur de l’un d’entre eux, le changement sera bien évidemment appliqué aux autres ! EncapsulationUn sous-patch peut inclure une instance d’un autre sous-patch qui peut à son tour inclure une instance d’un autre sous-patch et ainsi de suite. Il n’existe aucune limite à cette encapsulation. RecursionUn sous patch ne peut inclure une instance de lui-même ! vvvv ne vous permettra pas de créer une telle structure. Il existe plusieurs alternatives pour implémenter des algorithmes récursifs. Lisez la page Nodes Spectrales ou plongez dans le développement de votre propre plugin C# pour résoudre ce genre de problème ! |
Lorsque vous gérez les fenêtres de votre patch, soyez bien sûr de comprendre la différence entre fermer et cacher. Lisez le paragraphe sur les Modes de Fenêtres pour plus de détails. Notez aussi que vous pouvez empiler des fenêtres les unes sur les autres pour économiser de la place sur votre écran. Référez-vous à la section Docking pour plus de détails. |
3 scenes avec le mode Debug Timing enclenché.
|
Il est parfois nécessaire de mettre en pause l’évaluation d’un sous-patch lorsque sa sotie n’est pas nécessaire. Sachez que chaque sous-patch dispose d’une pin cachée Evaluate, par défaut seulement visible dans l’Inspektor. Désactiver cette pin stoppe l’évaluation d’un sous-patch (et par là même de ses enfants).
Ne mettez jamais de nodes recevant des infos d’un périphérique physique (souris, UDP, TCP, MIDI) dans un patch que vous désactivez. Ces nodes pourraient toujours recevoir des données même quand le patch n’Evalue plus, ce qui peut donner lieu à un comportement inattendu au moment de la réactivation du patch.
|
Les modules sont en fait des sous-patches créés pour être utilisés comme des boites noires (c’est-à-dire que l’utilisateur n’a a priori pas besoin d’ouvrir). Afin de faire un module à partir d’un sous-patch, procédez comme suit :
|
anonymous user login
~1d ago
~1d ago
~2d ago
~4d ago
~15d ago
~24d ago
~29d ago
~1mth ago
~1mth ago
~1mth ago