Long performance host patch

After making a few cool patches (which is easy to do!) I would like to make a host patch to make a kind of modular set (that I could play from 9p-5a without crashing or need of mixer). The host could load patches and get out put from node from either ex9Layer or a texture from the renderer.
What has the community found outways… getting raw high quality objects and keeping the onlyrenderer in the host? or using the un-aliased texture output of the renderer and mix two patches alpha vj style? Does anyone have any solutions to vj-style mix raw ex9Layers?

Has anyone ever noticed hickups when loading patches live into a currently playing patch and plugging it into a group or switch? (I guess I will find out after I try enough…)
p.s. I thought about posting in modules as I am kind of making patches into modules and loading them in and out with head module, but patches seemed more correct…Thanks everyone.

I’ve made a patch switcher, which is on my user page, only issues are loading patches will always create a pause in the output, you can spread the create node id and patch names too so you can do an a-b patch but you will still get pauses when you switch, but you can fade between them once loaded. Fast hard drives may help…

sweet dude, thanks for the advice and the basis patch. I do have RAID0 on two SATA drives in my shuttle (on steroids…), so fast drives is a go. Small paused might be worth not having a video mixer and backup… The video mixer kills quality and sharpness which is what I love about vvvv, cleanliness.
Have you ever had host patch crash (I have never experienced crash with XP only vista64(which I no longer use, it was a test OS give me a break…)

i once successfully patched live for 5 hours (main dx9 output & monitoring in root patch, creating subpatches on the fly, connecting/disconnecting stuff and generally causing a big mess) without crashing vvvv.

on other occasions, vvvv crashes quite frequently on me; i feel that vvvv is quite stable as long as your spreads are not too big and you are not doing any cpu-heavy stuff. also, when patching live, try to avoid doing anything you have never done before ;)

and if you are working with prepared patches, and they are doing fine (no errors in tty renderer on loading), you can be almost certain that vvvv won’t crash no matter how long it runs. i don’t know what the record is for the longest running installation, but i think i heard oschatz talk about several months (interrupted by hardware failure in the end).

I have done a set recently in which I was plugged into my mixer and could close patches and open new ones. Acted perfect and rather robust all night, but I had the chance to restart with every version of every patch I ran…

Catweasel: Your patch is very efficient, and a different approach than I had in mind. However your concept solves the problem of too many spreads/LFOs by having two patches open at the same time and crossfading, Which is why I was asking about load lockup. I wish in instances like this we could have vvvv multithreaded as each render chain would open its own thread, but I guess it all goes to the same renderer which would have to be in the same thread… I’m no super coder, I really dont know what Im talking about here… but it’s late.
Lovin You

Has anyone ever noticed hickups when loading patches live into a currently playing patch and plugging it into a group or switch?

Sounds like a delay caused by loading textures into graphic card, as soon as you connect a subpatch into your final renderer.
Too avoid this there are several ways, first, preload all your textures by having them all into one folder and load all pics in this folder into a quad in your final renderer, set to invisible. Second, optimise your pics by saving them as .dds. So, there is not too much delay as .dds is the native graphic card picture format. All other formats like bmp,jpeg,png,… will be converted inot this first. Third, try this “load in background” pin at the texture node. Never tried it, so may be some other can report.

vvvv multithreaded as each render chain would open its own thread,…

There have been a discussion about this topic quite recently. Check Vvvvorums. V4 can run onto different CPUs simultanously. But then output will too. So you need to stream your image from one V4/CPU to your “main” V4/CPU. This can be done by Freeframe FugStream up to 640x480px at localhost/TCP. And will have minimum one frame delay. Or try shared MEM node.