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