Multithreading or different framerate

vvvv beta question
#1

Hi,
I have a problem related to the fact that doing pixel access with Pipet (EX9.Texture) is very slow (as is expected). I don’t need that exactly realtime though - only as frequently as possible while the main (interactive) patch runs at full speed.
The way to go about this would be some kind of multithreading in VVVV. One straight-forward way would be to have multiple VVVV instances running that would communicate via Shared Memory. But it would be a little cumbersome to always have to start two separate instances - is that really the only feasible implementation of two different graph-render speeds?
Ideally I could use some sort of asynchronous messaging (like shared memory) in the same instance of VVVV.

Any thoughts are welcome :)

#2

if data can wait, why not split the pipet load into smaller parts, do the calculation in lets say 4 frames rather than 1 and queue the result. jut a quick thought…

#3

Have you looked into accomplishing the same thing with FreeFrame? It should be a lot faster.

#4

I think we need better implementation of Pipet via dynamic plugins. Color picking is very needed feature, but it’s just unusable now.

#5

Well I think I will write a dynamic plugin then that will do this threaded - ugh. Oh well I should wrap my head around C#-threading anyway…
When I do, I will try to make it as generic as possible and share of course.

#6

I’m already made simple face tracking dynamic plugin and pipet will be my next task. The problem that i was faced - the is no generic “Texture Input” type available at this moment. You can check discussion in this topic - http://vvvv.org/forum/texture-input-into-dynamic-plugin

#7

for now i don’t think the option of having multiple instances of vvvv running is too bad. you can start them all at once with a .bat file and also note SetProcessAffinityMask (Windows) that allows you to move the different instances to specific CPUs.