How do you guys manage complex patch organization in vvvv gamma?

[anastasia]

Hey everyone,

I have been diving pretty deep into vvvv gamma & loving the flexibility it is wild what you can build with it But now that my patches are getting a bit more complex I am starting to feel such as I am losing track of things. 😅

Also I am trying to keep everything tidy using regions and subpatches but sometimes it still ends up looking such as a spaghetti monster. How you folks handle this—any tips or tricks you use to keep things clean and understandable?

Do you follow any naming conventions, color-coding or maybe even some kind of visual “folder structure” logic? Also do you rely on any external tools or documentation systems to map out bigger projects?

Also i have check this resorse Firmata-Arduino example patch from beta to gamma blue-prism-training Want to hear how more experienced patchers approach this— when working on long-term or collaborative stuff.

Thank you.:)

[antokhio]

I’m not sure what to suggest, since every project kind’a brings it’s own logic, mostly you want main class - process node, that handles logic, and and a process node that get’s main class as input and access some properties of main patch as methods…

VL.Composition.Example.vl (23.9 KB)

[seltzdesign]

I would say from experience:

• use the Model, Runtime, Editor principle - ie. have a (data) model with all your parameters, variables, whatever you want to call them. Create a record and then have records inside it for all the things you will need. Try to keep the records small and modular.
• if you want to make your life easier and/or want to use ImGui, use GlobalChannels with the SubChannels module. You can just hook up your record to it and you instantly have your data model as Channels
• For organising it sort of depends on how large things will get, but I tend to start just putting all the records, processes and operations in the definitions and place them in areas. Once that gets too much I will create either a new category in the definitions or a new file and reference it as a dependency, if it is something I might want to use elsewhere or just keep separate so someone else can work on it more easily.
• Use GitHub!. It works surprisingly well with .vl files, especially if you use MergeVL. In the last few years of working on large projects collaboratively, I can’t really remember it ever failing to merge.
• I leave a lot of comments around, create groups around things and generally try to keep things tidy
• But of course also just embrace the “mess”. That’s what I love about vvvv and visual programming in general - even when things look messy, you can still follow the logic.

So these are just some general tipps that come to mind. Happy patching!

[chk]

@seltzdesign

use the Model, Runtime, Editor principle - ie. have a (data) model with all your parameters, variables, whatever you want to call them. Create a record and then have records inside it for all the things you will need. Try to keep the records small and modular.

Very interesting! Would it be possible for you to share a simple example patch regarding this workflow?

[bjoern]

@chk

Very interesting! Would it be possible for you to share a simple example patch regarding this workflow?

Model-Runtime-Editor design pattern - Model-Runtime - 1/6

[01_Model-Runtime] Model-Runtime This is part of the video tutorials about the contribution Model-Runtime-Editor design pattern Intro Part 1: Model-Runtime Part 2: App Part 3: Implementing a basic Model editor Part 4: Create new Model in Patch Part 5: UI Editor Part 6: Model over network

Edit:
GammaLauncher follows this pattern if you want to check out a “real live example”.

[seltzdesign]

@chk

Very interesting! Would it be possible for you to share a simple example patch regarding this workflow?

I think there was some Node session about it - I’ll try and find it. But yeah, I’d be happy to share my workflow for this in a longer session, because I feel like by now I have a pretty good understanding how to start a fairly complex project from scratch.

You can check the help patch: Global Channel of own Datatype to get the basic idea.

I tried basically building my own version of that patch, but somehow the SubChannelsModule doesnt do anything in the latest preview.

Probably best to wait for stable 7.0 for this stuff. I know there are some significant changes planned when it comes to Channels.

[chk]

Yes, I know the series from Natan, it would be nice to have a little collection of different approaches. @seltzdesign, if you could maybe just provide a very reduced demo as a patch, how you start to structure, that would be a great resource!

[Hadasi]

Community Coding : Design Patterns

hei all, I started reading this book (Head First Design Patterns, O’Reilly) that gives an introduction to design patterns and thought it would be a nice exercise to try to implement those in VL. Then, @sebl suggested it could be a cool communitythingy on the forums, so let’s do it :) I’ve set-up a repo so anyone can contribute and see what’s going on. The idea would be to produce a series of documented patches that could serve as a learning resource for anyone interested in the topic. Also, y…

[gregsn]

off topic:

I tried basically building my own version of that patch, but somehow the SubChannelsModule doesnt do anything in the latest preview.

We actually tried to keep the upcoming changes isolated in a branch. But that said: Did you try to use the SubChannels node instead of the SubChannelsModule node?
If the problem persists please open a new thread for the bug report. Thanks!

[tonfilm]

@david and @seltzdesign, how about developing a vvvv workshop for this topic?

[seltzdesign]

@tonfilm

how about developing a vvvv workshop for this topic?

I’d be totally up for it! But I’ll wait for 7.0 stable first.