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.