This should be simple, yet after all the years I still run into this problem:
If I fill IOboxes with values generated by a subpatch, then disconnect the subpatch, the IObox keeps the values (so I can work further with them; i.e. coordinate sets). But not always. Sometimes after disconnecting the IObox snaps back to its initial values.
What is the system behind this behaviour?
basically an iobox that has its input disconnected should always keep its values, except: when the iobox is in a patch that is instantiated more than once. in this case the behavior is not determined since those instances could have different values at the moment of disconnection but obviously only the values of one (random) instance can be saved. see?
mhh, well. I had lots of occasions like mfo where an IOBox wouldn’t save anything upon being disconnected, even outside of a module. Just resetting to its default values. Couldn’t find a pattern when this would happen so far, but I’m quite used to this behaviour - so it has been around for a long while.
May be related, also had a node which would reset to its defaults for a pin when I disconnected an IOBox from it …
if not in a subpatch then it sounds like a bug that we need a demo patch for.
i see. often have that problem with configuration subpatches that of course are instanciated all over the place. just openend one config patch from a recent project outside the bigger picture and it indeed fixed that behaviour.
however, most of the time the disconnection-changes-values issue does not occur anyways. kind of what would be great to have: for multi-instanced subpatches the latest change of an IOBox affects all other instances too (if not otherwise connected of course).
that is of course the case. it cannot be any other way. think of an iobox in a multi-instanced subpatch as a constant to that patch-class. it actually only exists only once internally and can therefore also only have one value.
if you disconnect the input of on iobox in a multi-instanced subpatch and don’t see it keep its values (which is what you want) this is just by coincidence that you’re watching the first instance of the patch. all other instances though will now have the same values. that is why you may think it sometimes “works” and sometimes doesn’t, when in fact the behavior is always exactly the same. hope that explains…
You mean that I’m not watching the first instance, no?
Meaning that if I edit an IObox in the first instance of a multi-instanced subpatch it changes the equivalent IOboxes in the other instances too, right?
And that if I try connecting an input to an IObox in an instance that is not the first instance, the IObox will revert back its values after disconnecting the input. Right?
ou indeed i had a typo in my last reponse. here is the sentence again:
if you disconnect the input of on iobox in a multi-instanced subpatch and see it keep its values (which is what you want) this is just by coincidence that you’re watching the first instance of the patch.
so you should understand that if you have an iobox in a multi-instanced subpatch its values are the same for all instances. if you want different values for each instance those values have to come via in input to the patch.
which makes a lot of sense in general, only for config patches it is a little painful. if i change an IObox (in a multi-instanced subpatch via some helper patch connecting to the IObox’s input), i would want it to keep that value across the board. so, i guess that would be my feature request / wish for some future version.
thanks for all the clarification joreg!
oh and is there a way to see if i’m in the first instance of a multi-instance patch? or trial and error only?
you can use the Instance Index in Self (VVVV) for this. but!
without understanding exactly what/how you’re doing it, i’d guess you’re doing it “wrong”. problem is it will be hard to make more thorrow analysis of your needs without seeing your actual patch… i’m just saying it feels “wrong” that you’d want to rely on the instance-index of a subpatch…
Aha, Self (VVVV) is indeed helpful.
And of course I would rather not have to look at node instancing at all.
I’m using config patches, those keep heaps of values that are all static at run time (of course: vvvv app runs all the time, but you know what i mean), i.e. midi controller settings, dmx configuration etc.
So I instance the config patch a couple of times across my application, i.e. in subpatches dealing the midi in/out, or subpatches about dmx interfacing.
For that, as said above, a behaviour like this would be great: for multi-instanced subpatches the latest change of an IOBox affects all other instances too (if not otherwise connected).
If one really needs to use multiple copies of a module (which often one doesn’t once the mind is set to spreading) then it will help to use common IOBoxes on the outside input pins of the modules, to set all copies at the same time.
In your case this does not help, I assume.
Module pins can actually have 2 values, one set from within, and one set from without. If ever a change occurs to a pin from the outside, it will then override the one from inside. And you don’t see the difference, a module with manual changes will look just the same as a fresh copy, even though they behave inconsistently, just as you observed (btw, I am glad VL addresses that).
Your config-usecase sounds like an interesting launching ground for vvvv-Message though, so give it a spin if you find the time. Used right it would allow you a performance gain if you just want to broadcast config data once (or infrequently) into your application’s many modules.
if you use the patches as config only, can’t you just keep the values in the ios inside withouth making them input pins? if you need to change them, just open the patch and do it inside and all instances will hold the same data
this to me sounds like you have global settings that you want to organize at a central point but access in different parts of your system. this is good and a standard usecase.
the way i’d solve this is having one instance of that GlobalSettings patch that holds all that config-data. inside that patch are S nodes that provide the settings for anywhere else in the system to be received via R nodes.
and again: this is the exact behavior you get. change an IOBox in any instance and it immediately updates in all instances.
Just to clarify: my config patch has no input pins. And nothing is connected to the inputs of my IOBoxes within the config patch - except for occasionally used helper patches, i.e. to generate bigger amounts of coordinates. I connect them, fill the IObox, then disconnect them right away.
Sometimes they IObox keeps that data (probably first instance), sometimes it looses it (probably another instance). And that is what I meant with “for multi-instanced subpatches the latest change of an IOBox affects all other instances too”, joreg.
Anyways, thanks for the hints!
S and R nodes … will try them out. Those work without delay? (Like: content send at start-up is received at start-up, without a delay of one frame?)
velcrome, with vvvv-Message you meant S and R too or ((contribution:message-2.0 (Something I actually had wanted to try long time ago… just didn’t.)
Ah, I see you meant Message-2.0. It’s your baby ;)
yes, S/R are without delay. they are actually a normal connection/link that you just don’T see.