If I create a new S(Value) node, save the patch, close vvvv, open it again by doubleclicking the patch, then the send nodes will not have their SendString anymore, but just the devnul String.
If I open vvvv through doublecklcking the .exe and then open the patch manually, it starts correctly. Using a batchfile or RemoterSA/PSTools works ok, too.
I thought it had something to to with boygrouped nodes, or nodes created on a Server, but it doesn’t.
I’ve had a problem where if I modified a patch that had Rs in it on one machine, and copied that patch over to another machine, I would see this problem. I found I would have to copy the entire folder over to keep it from happening. Some kind of cache info conflict/getting stale?
Hi mediadog !
R nodes may come to null if you are jingling from beta 23 - 24 - 25.1.
there is a kind of incompaibility in enum pin system and global variables with different versions of vvvv ( big transition in 23 > 24)
Troubles with S and R nodes can be fixed by constantly connected IOBoxes with variable names. It’s also helps other coders understand your patches. I’m attached help patch for better understanding.
i can NOT second that. i often use S/R nodes of all datatypes.
once you create a R node you have to modify the “Receive String Enumeration” at least once, otherwise the pin will not be created within v4’s XML.
but in case you have only one S and one R node there is no choice within the enumeration.
trickaround: create a second S node. now you can change the enumeration once.
we tried enos send patch on our machines with the result that
beta25 indeed shows devnul, however independent of the way we opened the patch, which is scary
beta25.1 however doesn’t behave buggy in any way (on this behalf)
the way how enumeration values are stored within v4p files didn’t change in any way. so how should there be any incompatibility between those versions? obviously there are just bugs in earlier versions, but not incompatibilities.
luckily and sadly its the newest version that seems to us to be the best recommended version regarding this issue. Luckily, since it doesn’t seem to have the described bug, sadly that you see it different.
we only cache meta information about addons (plugins, effects, modules). no further information is cached.
so for me this makes only sense in one way: you somehow missed to copy the patches holding the send nodes to the correspondig receive nodes. without sender a receiver must behave erroronous.
so anyway we will keep on tracking the issue. however if you have a way of reproducing the bug(s) (that is reproducable over here) please keep us updated.
thanks to kalle for again pointing out a certain bug regarding the initialization of enum input pins.
sorry for that. if you can pin the problem down a little more, please help us to track that down, ideally in another thread.
hi gregsn, do not apologize please !
i know that i dont know anything about the inner structure of VVVV. But lets say that I may have a certain kind of sensititivity to VVVV, wich makes me feell tings like Kalle: Having a certain empathy from patchs and projects. this is irrationnal … I Know…
I completely understand what you are saying about v4 storage system. But from experience and pain with enum and global variables, i know that the issue is somewhere in protection or initialisation of enum structure in memory. I would rather say mem allocation. this was for 23 24 and 25.1.
i m waiting for new project ( dont know when), as it is inside big project that those errors occurs, not on tests, to tell you if you succeed in eradicating that bug. Please do not be sad, or angry, about bugs. this requires time and the tool you are developping is really great. thanks
This happened using a utility (FolderMatch) that only copies files that have changed. I have it set to look at size and modification date. So unless vvvv is modifying those patches without changing their size or date, I don’t see how I could have missed a copy.
Like karistouf, this only happens on a rather large set of patches that I cannot reduce to a test case.
An excellent suggestion. I have been putting the variable name in the node name so I could see them, but this is more robust and obviously better. Thanks!