[PD] a flawed Gem (Was: Re: pdp/pidip on win32?)

[John Harrison]

cyrille henry wrote:
> hello,
>
> 1-> i don't know where the problem is. But i don't think it is in Gem, 
> since Gem does only control the graphic card.
> upgrade you graphic card could help.
Other opengl apps don't have the problem on teh same machine, same OS. 
Not saying you are wrong though.
>
> 2-> Yes, the Gemhead concept in Gem is different than pd concept. it 
> is this way because Gem is very close to openGL concept, and that's 
> why Gem works so efficiently. See documentation about OpenGL for more 
> info.
This is what I am finally getting. I had thought of Gem as an extension 
of Pd into video. Now I am starting to see it as its own language with 
its own rules that shares some ideas with Pd and borrows the Pd 
environment. If this had been clear to me from the beginning of my 
exploration with Gem, I think it would have been a lot less frustrating 
for me to use.

Anyway, I now get, understand, and respect why this would be the case. 
Is this explained in the docs anywhere?
>
> 3-> what you describe is a missing sinc to vblank. Be aware that once 
> you set this parametter on the driver, you have to choose on wich 
> screen to sinc, and to restart pd/Gem. Nvidia driver are the same for 
> lot's of different hardware, it's possible that you have this option 
> in your drivers, but your hardware is not able to do it.
Yeah I had the same thought and tried exactly this. I saw glxgears 
reporting different numbers when sync to vblank was set so i figured 
*something* was happening. But the video problem remained.
>
> 3b-> i don't have a firwire cam to test, but i saw strange thing in 
> you patch : -why do you use spigot?
> -why do you connect many time on the same camera?
> can you try the attached patch, and tell us if it is still crashing?
The idea was to build multiple sub patches, each independent of each 
other. So if you closed the Gem window in one sub patch, the signal 
chain was also completely freed for the next sub patch to use.

What I am getting now is that there is no was to completely "turn off" 
[pix_video]. Once the object is created, it tries to communicate with 
the video capture hardware, etc. So there should apparently be only one 
[pix_video] per video object per patch. Is this documented? It's 
certainly not obvious. You can have multiple [adc~ 1] in a Pd patch with 
no problem.
>
>
> 4-> i think there was some bug report about this issue regarding 
> pix_record on linux.
> don't have time to check.
Yep. From 6 months ago. Also a different problem.

For me [pix_record] has been very temperamental so I have had trouble 
building a small example patch that doesn't work. What happens to me is 
that in the midst of building a large performance patch, suddenly 
pix_record either starts segfaulting or will only record a few frames 
then stops (closed Gem bug 1849187). It is bizarre because it will 
happen when I am working on a completely different area of the patch 
that in my mind at least has nothing to do with the signal chain of 
pix_record. But then if I take out the new area, maybe it will start 
working again.
>
>
> 6-> pix_motionblur does affect images in the buffer, because Gem did 
> not copy images from the buffer before using them. This is the way to 
> have good performance. of course, you can force Gem to copy the image, 
> using pix_separator.
Yeah I never knew about pix_separator and didn't know to look for such a 
thing because, again, I was expecting objects and dataflow to mirror Pd. 
Now that I know not to expect that, I can understand and respect this. 
Yes pix_separator probably solves the problem. Thank you.
>
>
> Sending 1 mail for 1 problem would be easier to discuss.
Ok. I'm still trying to figure out how to be most helpful. I have been 
having trouble with pix_freeframe so I submitted that as a bug in the 
Gem sourceforge tracker, hoping that was the right way to approach.

Thanks for this conversation. It is really clearing up a lot in my mind 
of how Gem works. This is making it possible for me to imagine 
introducing it to my class I have coming up, and I really appreciate that.

-John