Send Nodes losing their SendString

Hey Guys,

this is a reproducable Bug on 25.1

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.

Can you confirm this?

Here’s the patch:


send.v4p (1.1 kB)

confirming that beta25 and 25.1 have troubles with S R (node), also with simple patchs

I’ve also had patches that are missing subpatches and/or plugins when you start the patch, but not if you start vvvv then the patch…

well, the sendstring IS contained in the XML.

but even in beta23 it opens with ‘devnul’…

yes i tend to do as catweasel open vvvv then the patch this solved me some problems in 25.1

got the same today on another (huge) patch :-/

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?

Hmm, to further clarify, what I see is that the R nodes go to devnull, not the S nodes.

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.

S and R (convention).v4p (5.2 kB)

Same here. I really try to avoid S’s & R’s since day 1 as they always made trouble at some point…

@alg: i m using a lot of S and R and i can pretty insure you that there is some enum bug around not yet solved wich is producing NIL result

@karistouf Hmm, yes i think IOBox enums sometimes can produce NIL, but it’s not the S or R bug anyway.

@alg: S and R are using enums … the bug is inside enum structure. May devvvs found the bug ( amen ! )

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.

be aware not to use the CTRL-D future with S node tagged with a name. This is bugging heavy patchs somehow.


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.

thanks and all, greg

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!