Workaround for render freezing during file loading

vvvv beta general
1

Hello!

Has anyone found a workaround for the render freezing when you load a file in VVVV? I saw the “Selektor” patch from wombot, I tried it, but it doesn’t work on my machine. It says something like socket.error(10048, ‘Address already in use’). I have Windows 7 as OS.

2

You could make and additional patch that runs in a separate instance of vvvv communicating via UDP or TCP thus having the file chooser freeze only the patch choosing the file leaving the other running fine.
Use the parameter /allowmultiple in args.txt to run several instances of vvvv.

sunep

3

Yeah, good idea! I have to try it. Thank you!

4

SUNEP do you have perhaps a small example or a link how to communicate through UDP/TCP from one instance to another? I searched for the UDP/TCP documentation, but unfortunately there’s only some help for OSC.
Did you mean to open the renderer in one instance of vvvv and the file selector in the other?

Thanks in advance!

5

if you only transmit values you also can use
*DMX (Network Artnet Sender)
+and
*DMX (Network Artnet Receiver) .
no need to specify IPs and Ports!

some helpful conversion nodes can be found at kalle.Modules.DMX.Universal

6

HI cybear

I have attached an example. I did not realize that the file choosing dialogue do not appear when you have attached the IOBox to a file choosing input and somewhere else. so you can either do it in a way like in the example I have attached or just make an IOBox in your original patch and drag-drop your new files from a windows explorer directly into vvvv. or have that separated. I usually use directories and load a whole directory of names using the Dir node and then use GetSlice to pick the file I want.

but attached is a small example on how to send file names over network.

sunep

udp-filechooser.rar (3.5 kB)

7

and yes, I did mean to open the renderer in one instance of vvvv and the file chooser in the other

this also leaves it open for you to place your interface on a completely different computer so you can offload that from the main machine and do adjustments in the control patch without making the rendering patch stutter.

8

Thank you very, very much for all these replies!!! It’s very kind of you. Have a nice day.

Ciaooo

9

since one and a half year we have OpenFileDialog from vux… its in the addonpack and does exacly that…

10

What I’m actually searching is a way to switch v4p-patches without stuttering. I’m working on your svvvitcher tool which I like a lot and did a lot of changes. I added RGBA slider for the channels, two different beat calculations, beat automation for every parameter, infinite patch and postfx adding, a preview monitor and a lot more…
It will be the mixing tool for my design dissertation, hope it is ok for you. Obviously I mention all the people who worked on it.
Afterwards, if it is worth I will put the final version on the website.

I attached a screenshot of the actual situation of my version.

_root_MAIN-gui_2010.04.13-17.43.10.jpg (232.2 kB)

11

What I’m actually searching is a way to switch v4p-patches without stuttering.

very sorry, but that is not possible by design. loading a new patch into the current render graph will rebuild the graph. only thing you can do is decreasing the loading time by preloading the resources a patch uses… but i assume you do that already like svvvvitcher was doing it.

I added RGBA slider for the channels, two different beat calculations, beat automation for every parameter, infinite patch and postfx adding, a preview monitor and a lot more… It will be the mixing tool for my design dissertation, hope it is ok for you.

this is absolutely ok! it looks really sophisticated and i hope you will upload it so others can use it.

but i want to add, that the philosophy of svvvvitcher is quite different. it was designed to provide a very fast and slim framework to switch patches while leaving as much as possible performance for the patches. so the focus is on the patches, not svvvvitcher, because the patches are the actual output.

so i added only some parameters for the patches and the post fx. i dropped the preview by intention, because it will double all resources once you drag the output renderer to another screen, which will most probably halve your framerate and videos will only play on one screen.

but then the preset thing was there for almost no cost, because it only loads small bitmaps and you can save nice settings you want to recall with just one click.

and all other effects i leave up to the patches, because in a patch you can do just everything.

but thats the tradeoff, which effects are so general that you want to combine them with all patches, and which are more specific and you put them in your patch… for me, the most important thing was render performance, so i decided only post effects are general enough to make it into svvvvitcher. thats personal taste…

thats what i wanted to share from my experince and i hope it will help you to improve your code.

but nevertheless your work looks very impressive and maybe its a good basis to make svvvvitcher v2, which is in my line since last summer…

so, keep up the good work and we look forward to see your result up here soon…

all the best for your dissertation,
tf

12

Thank you tonfilm for your reply. I supposed that it is the reason why it’s not possible to switch without stuttering. I was thinking to try a way to open two instances of vvvv and split the work in two that one vvvv instance works on the createnode-patch and the other on the renderer. But I saw that through UDP/TCP and other network protocols it’s not possible to transmit DX9-Layers; only string or values are possible to send if I’m right. I even tried to translate the texture to string and send it trough UDP, but its even worse. If the createnode-patch would have a “do it in background” or something like that feature than probably it could work.

Anyway when I added features in svvvitcher I always pay a lot of attention for performance. For example I gave the possibility to put off the preview monitor (on the lower left) if the FPS goes to low or if you have a hardware monitor attached on your computer. The additional graphics are just one background image and nothing else, I wrote the code for the RGBA sliders in HLSL using an FX-file instead of vvvv patches, I rewrote the rotary faders, because the vvvv rotary slider patch builds segments which have a lot angles, and my rotary faders are just rotating tiny quads, …

At the end I want to make a performance comparison if there’s a lot of difference between your version and my modified version.
Some difference would be there for sure, hope not too much!

Thank you very much for all these useful information.

Ciao
cybear

13

sounds very promising, i think my code is in good hands!

there is one idea you could try when you want to go the two (or even three) vvvv instances way. you could write the textures of the loaded patches into a shared memory handle and read them in the main instance.

never tried this, but have a look at the shared memory nodes…

good luck!

14

Hello Tonfilm!
I tried working with the SharedMemory (EX9.Texture) patch, but I think it is not the right way, because you lose a lot of FPS (just 24-30FPS?) and it seems to have even some image quality loss too. The problem is also the sending part, because the EX9.Texture has to be converted in DirectShow (AsVideo patch) for sending it trough the VideoOut (DShow9 SharedMemory) patch. Or is there maybe a more direct way to send it which I missed?

Thank you anyway for the hint. Perhaps it could even help to find a way to open the v4p patches with another algoritm which doesn’t freeze vvvv, so it would be in memory and afterwards do the createnode command? … I’m just fantasizing! Hehehehehe :D

15

sorry I saw that the MainLoop patch helps if the Time Mode is set to Increment. I’m going on with experimenting. If I discover something helpful I let you know

Ciaooo

16

be careful, setting the mainloop to incement changes the internal time calculation, it does not change the actual frame rate, look at its help patch…

17

Yes I noticed it, it doesn’t make sense. I was wondering myself if it isn’t possible to access to the DX9 layer through shader registry addresses…
I’m a real beginner with HLSL programming and I’m trying to find some good books or stuff to learn it better.