In most of the larger projects that I’ve done, I get to a point where I start to think about consolidating control. For example, having a single (sub)patch which contains a bunch of IOBox (Value Advanced) nodes which control parameters of various components within the system (such as a few boxes to control one renderer and a few to control another all in one place). This can be accomplished using S (Value Advanced) etc. Due to its ability to have multiple senders on each channel, you can have multiple IOBox (Value Advanced) nodes that control the same parameter, and it takes the value of the last one to change.
The same sort of issues apply when I start to add MIDI control (or Timeline, etc). Eventually I end up with an arrangement where there will be several sources of values for any given parameter of the system (GUI control, MIDI, etc).
I seem to always end up encountering problems with this approach, such as what values are present when the patch first opens, confusion about why something has value X when the IOBox in the patch itself that is intended to set it has value Y, etc.
In Max/MSP, I’ve generally solved this using their pattr (patch attribute) system, which allows you to have multiple nodes which bind to the same underlying value. Setting the value on one of them sets it on the others, etc. You can then bind UI controls to these values, so a knob will change when MIDI input changes or whatever else.
There seem to be some fundamental aspects of VVVV (such as frames/node trees vs. messaging, shared instances of subpatches) that don’t quite fit with this concept. The biggest problems that I can think of are around preventing loops in node graphs. I haven’t quite come up with a way to get around this, and I suspect that it might require changes at a deeper level than one can feasibly implement in a plugin.
Any thoughts/ideas?