So I’ve got vvvv running in 2 separate threads, but I was hoping to use artnet to communicate as I’m already doing that in the patch at the moment, but the second instance of vvvv cant create either a send or recieve artnet node.
I dont know if this is a bug and fixable or whether its just not possible so I thought I’d put the question here!
The other question, which would be the best way of communicating between instances? UDP and osc nodes both can be created, but I’ve not used either as yet as I’ve always just used artnet, which would be the fastest easiest method?
Hmmm the udp nodes load but dont seem to recieve any data…
I presume the port is opened by an already running instance…
Any ideas, apart from midi and loopback, id like to keep it 0-255 and Im already using 120 channels…
The operating system will not allow two different programs to listen to the same UDP port.
That the node can not be created seems to be a bug. The expected behaviour would be that one of the nodes does not receive any data anyway - As they work on the same port.
And as the Port number of Artnet is fixed in the specification, we did not provide a way to change it.
On the other side, the UDP nodes are be flexible enough to do what you want. just make sure you use different channels for each sender/receiver pair.
@Tom, I just copied and pasted the exe file, then double clicked one then the other, then switch the threads. I did a search for the args command but couldnt find it…
I think launching via command line then switching affinity automatically is the next step for process() having different named exe’s helps there as there names are different, I think otherwise you would have to determine the thread no. then switch.
@Oschatz, I did play around for a while with udp, but couldnt get any data, I’ll try again later, if it works it would be an easy way to make use of these dual core processors you cant get away from these days! I suppose the ultimate wish would be an S and R node that works between instances of vvvv!
Having never played with the udp node I didnt realise how easy it was to use, my patch uses xml presets at the moment, so I could just send them straight from interface to output without any trouble, I’ll report back later!
As an update, I just tried running 2 instances again , and only one appeared in the task bar, after a reboot, got 2 again and udp works between the 2, further experiments follow!
Ok this should automatically launch and set affinity of 2 versions of vvvv, copy and paste then rename the copy of vvvv.exe, to vvvv2.exe, unzip the archive to the root of your vvvv folder, and let me know if it works for you!
Udp is working, after some searching I just saw a post about netsend, would that allow lower latency?
Have this all working in my patch now, at full wack both threads max out, in more normal usage I get 10fps on average better frame rates in the output. It’s a bit confusing at times sorting it all out, but the performance gains are well worth it!
I’m just using udp to pipe presets to the output, I’ve still more to do but the basics are all there.
I have got an updated instance patch, but all it adds are 2vvvv node to name each instance in the task bar. There seems to be a bug in vvvv as by default when you add the second node the task bar button disapears, you have to toggle the show in task bar button to get it to work.
ja. then netsend/netreceive is just the idea of your desired S and R nodes that do a simple sending of spreads via udp. i can’t think of an easier way.
maxing out…hm. standard problems of syncing two threads apply. both instances would need a rather constant and equal framerate for the communication being steady. or you’d need a filtering mechanism on the receivers side.
I maybe should have checked this before spending a couple of weeks patching…
it seems, you can only run one instance of vvvv fullscreen, my plan was dual head, with interface on one screen, ouput on the other, both running seperate threads, but I’ve just tried it and once one side fullscreens, the other renderer goes grey…:(
i dont suppose there is any way of getting this working is there, the performance gains are massive, and it would be a shame if its not possible!
( I’d even sorted out a preview on the other thread of the output, the patch is virtually complete but for this!)
Ahh, I can manully resize the window to the fullscreen then ctl+8 to get rid of the name bar, so can I request the saving of the name bar state for a future (soon please!) update?
Also is there anyway to find out the resolution of a display so I could dynamically set the render window size and position based on what monitor I have attached?
One more thing, if your running with 2 threads and using avi’s leave the output instance running on both cores and your interface on core 2, this lets directx use both cores for decompressing your files…
nnnnever noticed that myself, but i tried now and you are right. i don’t find any related infos on the net and don’t have any other directx applications at hand to try with them. the directxsdksamples won’t let you even close to starting a second application while one of them is fullscreen.
so probably this is really a limitation of directx.
“Also is there anyway to find out the resolution of a display so I could dynamically set the render window size and position based on what monitor I have attached?”
you won’t get the display resolution but using the Window (Windows) node you can set the Width/Height of a window =2 and it will fill the entire screen.
Thanks for all the advice.
here’s a method that works for me now:
put vvvv.exe, vvvv2.exe (copy of the first file), process.exe and the following batch file into your vvvv directory (batch file is also attached).
start vvvv.exe /allowmultiple
start vvvv2.exe /allowmultiple
process.exe -a vvvv.exe 1
process.exe -a vvvv2.exe 10
hey catweasel, I don’t know what you’re doing with your renderers but you’re talking performance. Just pointing out something that you may well know…
…depending on what graphics card you are using and what drivers are installed, either a fullscreen renderer performs better than a windowed renderer or the otherway around. For example a Nvida Quadro drivers are optimized for multiply windowed renderers where as the Geforce8 series drivers are optimized for fullscreen (optimized for games). These are pretty much(or are) the same card. You can trick the OS into thinking one is the other (using RivaTuner for instance) and install different drivers.
So… if you are going to use two windowed renderers that fill the screen you may want to check what card you are using and what drivers you are using.
I assume the same applies for ATI but I know nothing about them.