doing the CreatePatch module i realized, that there is no way of finding out which type of iobox (value, string, enum, color or node) a link would need.
there’s either the possibility to compare i with a huge list of pinnames or just creating all 5 types and connect to each one - the correct link will remain.
so couldn LINK just feature the attribute type=something?
another thing just noticed.
there is no way of deleting an existing link by using setpatch. (you could delete a connected node and recreate it again… but then you’d need to consider all its connections and its stored values)
edit: sorry, second case is wrong. just provide a wrong value to any attribute and the link disappears!
i’m sorry, i just didn’t have time to look deeper at your module, but somehow i think it’s a not too bad style to do the linking by sending the 5 actions.
but the second thing you mentioned: there are some attributes available which aren’t saved to file but should work (the are used internally also); might be wothy to look at…
attribute
deleteme = … (value doesn’t matter)
is for deleting nodes or links
there is an attribute
deletemedontask = …
which might work. just try it. maybe in combination with deleteme or not. ~
hehe, nice to hear, that there’re some more features!
concerning the 5 types:
it’s kinda heavy (performance) to autogenerate 5 ioboxes for each in and outlet. if not many in and outs are needed its ok.
furthermore its quite tricky to then delete the unused ones in the subpatch created. (had to create a bunch of nodes inside the subpatch, which would do the deleting and then delete themselves)
hum, how about a PatchAlias where you can also specify the desired patch by it name? just a thought…
hm. yes, probably it would be good to store the valuetype of each pin in the v4p. at first this information wasn’t needed for vvvv to load the patches, because this information is already stored in the code of each node. another way would e to have a nodereference xml file which outputs all these redundant information, which aren’t needed by vvvv but could be interestig for setpatch users. also the valuesubtype could be interesting… boolean, integer, float?! etc.
so maybe we should just generate such a file again which could be parsed by your patch?
PatchAlias with the name of the patch where the action should be applied to sounds like a good idea. but, isn’t it possible to just specify the name by using nodename attribute?
that should do the trick already. however you need to know the complete path of the patch.
but, isn’t it possible to just specify the name by using nodename > attribute?
not sure, if i got you right. but i don’t see a way to the “guts” of a fresh loaded subpatch from a module without connecting the subpatchs patch outlet to the module and then to a patch alias (for getpatch and setpatch stuff)
PatchAlias provides access to parents, but not to childs or siblings (correct name for it?)
so maybe we should just generate such a file again which could be >parsed by your patch?
would be cool! was already thinking about parsing vvvv.exe where this info seems to extractable.
but: a file with all the this metainfo… wouldn’t it be huge? → performance?
but the second thing you mentioned: there are some attributes available which aren’t saved to file but should work (the are used internally also); might be wothy to look at…
deleteme = … (value doesn’t matter)
deletemedontask = …
PATCH attribute
saveme = …
and attribute bgcolor…
are there more undocumented things? i’m greedy to know that…
@woei:
you are right it doesn’t work the way i thought. at the beginning of a setpatch xml snippet there is the PATCH tag. and in there is the nodename attribute which holds the name of the patch. internally this is used to find out which patch should be changed. but the node Setpatch works different and just uses the “Patch” pin for rooting the xml snippet to the right patch. so you are right. there is a node missing (or an option at setpatch to just use the nodename attribute of the PATCH tag for rooting to the right patch)…
the file would be huge but if the lookup is as simple as “check type of pin” then this should be no big performance problem when the xml file is already parsed.
for that the XPath node might need to be optimized for differing changing queries but unchanged xml docs. (david, björn?)
@kalle:
you found the bgcolor by your own, right? because it is saved to file.
the only other attributes which are not saved to file are the ones above and a pin attribute called “slices”.
if there are no slices specified in the action then perform action on all slices
if there is one slice specified in the action then perform action on this and all following slices
if there are more slices specified in the action then perform action on these slices
so you can set spreadcount attribute very high and just use small spreads for values and slices for small changes within the big spread…
btw: deletemedontask should be for deleting subpatches without being asked if the patch should be saved.
the file would be huge but if the lookup is as simple as “check type of pin” then this should be no big performance problem when the xml file is already parsed.
for that the XPath node might need to be optimized for differing changing queries but unchanged xml docs. (david, björn?)
Good point. i will have a look on that.
btw. the routing by patch name makes totally sense to me.
