Thank you a lot guys!
Thanks to your suggestions, this seems to be the solution (see attached patch). I have to try it on Mac though, to see if it really fixes the issue (hard to predict since the issue itself is pretty strange), but I expect it to.
I didn't expect the spigoting-the-gemhead-trick to work: I thought that having pix_movement receive the gemlist only some of the times a frame was rendered would cause strange interactions.
The pix_texture-right-inlet-trick even allows me to monitor the movement signal which is great.
On 04/05/2011 05:03 PM, cyrille henry wrote:
depending on the aplication, it can help to separate the tracking and the rendering on 2 diferents process (2 diferent pd). (most computer have multiple processor now)
to slow a gemhead, you can stop it (sending it 0) and then send it bangs with a metronome. if you don't use it for rendering it should work...
c
Le 05/04/2011 16:47, Matteo Sisti Sette a écrit :
On 04/05/2011 04:33 PM, chris clepper wrote:
I used pix_movement and blob for basic motion detection for years. I gated the video signal so it would only output every half second or second
How do you gate the video signal? That may be exactly the workaround I need
Try setting the GEM framerate to the advertised frame rate of your device and see if that helps.
Yes it does help, it fixes the problem completely. But that is not an option if i need to produce graphical output at a higher framerate. It's ok to detect the movement at a rate equal to or lower than the camera frame rate, but i can't lower the whole gem framerate because that will affect video output.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list