One word: WOW!
This, against any common sense actually worked. On Ubuntu Hoary running on the 100% same hardware and the *same* pd software revision this was not needed. Now suddenly this is required, go figure. More so, given that e-mails on various lists asking about this go back to mid-2005, none of which were apparently solved...
So, in short for Studio and others to try out:
1) Start the examples/Gem/04.Video/00.SimpleVideo.pd 2) Change device message to "/dev/dv1394/0" or if you have dv1394-0 device, then to "/dev/dv1394-0" 3) Change "driver 0" to "driver 1" 4) add a message to pix_texture "mode 0" 5) depending upon your type of camera you may also need to use "mode NTSC"
Click on mode (if needed), then driver, then device, then on the newly added mode, and then finally create gemwin and turn on rendering. You should now have a working dv feed!
Kudos to Chris for solving the riddle! I am still a bit confused why this is necessary (mode deals with "rectangle texturing" but since I was using the same version of pd/gem before and it worked without it, this is still IMHO very curious).
Best wishes,
Ico
On 12/31/06, chris clepper cgclepper@gmail.com wrote:
send 'mode 0' to pix_texture?
On 12/30/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
Well, here are my latest findings. I just spent 2 days trying to hack the dvgrab app (available from Kino, talks to devices via userland) and somehow merge it with Gem. I am pleased to report that the hackathon was successful but the results were surprisingly the same as before (talk about the DOH! moment). However, I did discover that actually both before and now the video feed *was* working. It is however as if the entire texture in Gem is covering either really small area (i.e. one pixel) or had some kind of mangled data that remained for the most part black. How do I know this? When I flickered with my hand in front of the camera and/or made drastic changes in lighting/exposure, there was slight change in color of the overall texture.