I have a quite complex project made in vvvv, consisting of many subpatches/modules. I work on it on two different computers. Several optional values used in several of the subpatches are different for the two computers, Midi ports also - so a decent way for configuration was needed. So I can have different config files/patches for different computers.
Thats why I created a “config” patch. And I made it a module to be able to use it in all my subpatches, which are usually modules too.
Is there a structural weakness? Should I have used custom modules only for basic tasks, everything else as subpatches, placed relative to the main patch??
What is generally a good programming technique for configuration in vvvv?
Enums for MidiPorts (outputs of the config module) get mixed up / are not constant.
It’s the same config module I use in several patches and only its output pins are used (I even dont want input pins, but cannot avoid those). The IOBoxes in it have the same value no matter where I use this config module, thus they are project-wide constants (thats what I need). But the Enums-Pins for Midi Ports of this module have different values in every patch I use the module. And they confuse their values everytime some-Midi-thing changes.
And how to clean that enum problem?
i guess the tentatively titled String2Enum node from the changelog for the next version might be the cure for that.
instead of placing the config module into every subpatch that needs it, you could place a single config module into your root patch & use Send / Receive nodes to distribute the data. but i’m not sure if this is really a more stable / clean alternative.
Send/Receive nodes … those didn’t come into my mind.
Hmm, well, the more I think about them, the more they remind me of global variables (i.e. in php). Which are a bit spaghetti-codish, as they can be set anywhere. (Right??)
For those String2Enums nodes - I’m hoping for beta23.
“remind me of global variables” - yes. Its in a way same with the subpatch-approach. Lets say in a subpatch is a rgba.node with a specific color as output and an alpha for your node as input, and you change the input alpha, then its not an global variable output anymore, but local… Because you changed alpha, which changes your color and give a different output then all other color-subpatches.
With send/recieve you want have opportunity to change at local base too, but at global base only. Personally I dont like S/R too much. I Like to see visually where vars are going too.
Anyway thats just some thoughts I found for me.
I did this subpatch stuff a lot for colors and IPs, but switched now to a config-file, which will be loaded and distributed at startup. Because its much easier for others non-V4-people to change some settings like IPs.
