Invisible patches

hello there –
I’m a relative newbie, having started with vvvv about a month ago. First I should say, it’s pretty amazing, and the work of the users I’ve checked out is very cool. I’ll be sure to try to get to NODE09.

So, here’s the question… I’ve worked on some patches, and saved them, and for some reason they won’t load. Nothing appears. Other patches load just fine (including previous versions of these same patches).

Could this be related to the “heaviness” of the patches? That is, if they were pretty processor intensive, would they refuse to load later?

Thanks for any suggestions – anxiously hoping to retrieve these patches.


*have a Renderer (TTY) open when you try to start those patches. what does it tell you?

*open those broken patches with a text- or better XMLeditor. may be that there are some e.g. IOBox (String) having some special characters stored in some pins. delete those characters, save, and try again.

if nothing helps, attach those patches here.

edit your patch with a note pad or an xml viewer, and look at visibility=0, change it to 1… but this issue is , helas, still not the only one cause … i begin to think that from time to time there is a migration of vvvv patches somewhere else on the planet ?

You tried to open the .~XML one? Rename it to ~.4vp and open.

I remember I saved a patch in fullscreen mode once and couldn’t get it open, do as Kalle says, and remove all references to Renderer.

thanks for all the tips. No luck, unfortunately, in spite of some tedious time spent editing the patch with the XML Marker app. It seems as if about half of the patch is missing in the xml doc.

The initial errors showed up as missing closing tags for and . I fixed those, but there is a huge chunk missing, so it looks like a large portion of the end of the file wasn’t saved. I also found a lot of height=0 and width=0 tags, and changed those to some default values. (Although I don’t know enough about vvvv’s xml format to do much with this.)

So, I’ve attached the file, in case anyone wants to take a quick look at it. As I said, it seems like the missing part of the patch is irretrievable (if the nodes don’t even show up in the xml). But hopefully I’m wrong about that.

Any tips for avoiding this in the future?

Thanks again –

P.S. – one of the files is the original corrupted file, and the other just has the missing closing tags inserted at the end. (4.9 kB)

I typed the xml format for “node” and “patch” in the message above, so they didn’t print in the post. Meant to say: "missing closing tags for “node” and “patch”.

You still have the .XML file (a file with .XML at the end? That is a back-up duplicate off the original patch!!

If that is also only 15KB I fear the worse for you :(

Yes, I have the xml file of a few versions, but unfortunately they are also only about 15KB. So the worst is true…

Well, I guess that’s the way it goes when you’re getting into something new. (Paying my dues, as they say.)

Anyway, I’m wondering if this is a common occurence/bug? Also, is there a place to change the timing of vvvv’s autobackup?


this is definitely NOT a common bug.

after closing the .v4p with

i could open it. but seems to be somehow incomplete

BRdeformpatch-x.v4p (14.8 kB)

I spent some more time in xml land, and did manage to resuscitate one of the dead patches. In that case it was simply an invalid value for an input for one of the nodes (an Input String node). Do you have any idea how this kind of thing happens? The patch doesn’t seem that complex.

by the way, I used a different xml editor ("PXE - Peter’s XML editor), which was better about locating the problem. It has line numbering, and tagged this one error right away, while the XML Marker app didn’t flag the error at all. (fyi - the PXE app seems a little buggy, but was still useful.)

the other corrupted patches are missing huge portions in the xml file, so really aren’t recoverable. Do you have any idea what would cause such a problem? (When I save, the save appears to proceed normally.)

thanks again –

…it was simply an invalid value for an input for one of the nodes (an Input String node)

that is exactly what i meant with my first answer.
if it was the "Input String"pin of the IOBox (String) containing those values i assume that you yourself typed those in to a commentbox.
did this myself occasionally.

when i do “driver”-like patches i often copy/paste the original docs into IOBoxes. sometimes they contain evil chars…

hi kalle-
thanks for all the help. Yes, it was your earlier post that let me know where to look in the xml file for the problems. In the end, I recovered some of the patches, and lost several others that aren’t recoverable. I thought that I would summarize this thread, just to clarify (it might help some other users).

In the end, there were two distinct problems: the first, where at least half of the xml file was not saved at all. After opening the patch file in an xml editior, and pasting in the obligatory closing xml tags for “node” and “patch”, the file loaded, but was of course half empty.

The second problem was more like you described, where there was simply an invalid value for an input on an Input String node. That was easy to fix, via the xml editor, and the patch did not lose any components. The PXE app I mention above was better at flagging the problem, in conjunction with reading the output of the Renderer (TTY) node as you suggested. After erasing the invalid value, the patch loaded.

I wish I understood the cause of the first problem – the one where half of the patch was not saved at all in the xml. That was the more worrying situation.

So, I hope I can move on to more interesting questions! Thanks again for the help.


Hi chaco,

were in this half-saved patch huge spreads?
Once I had trouble opening a patch and it turned out by looking into .V4p source code that two string input-tags werent closed. These spreads had have huge slices (7500). After just closing the tag it was fine and running again.
It never shown up again with this patch and I have no clue why this happened.

hi Frank,
In the .V4p source code there weren’t any huge spreads. It was just as if the file stopped halfway when saving. (I had been saving incrementally, so the previous version had about twice as many nodes.) It hasn’t happened again, so hopefully I won’t see that again!