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 :)
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…
Have you looked into accomplishing the same thing with FreeFrame? It should be a lot faster.
I think we need better implementation of Pipet via dynamic plugins. Color picking is very needed feature, but it’s just unusable now.
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.
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
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.