Spent the better part of today reverse engineering gridflow's "multiblob" example patch -- time well spent, actually, as I now have a much better idea what it's actually doing than I would if I had just cribbed the example.
The only trouble is, it's s-s-l-l-l-l-o-o-o-o-o-o-w-w-w-w-w-w-w-w-w, chewing anywhere from 30-60% CPU according to Ubuntu system monitor. So I'm wondering how to pick up the pace. My patch is attached.
First obvious thing is, reduce the image size by another factor of two. After [#downscale_by 4 smoothly], the image is 320x256. I may not need that much resolution, but I'd prefer to keep that as a last resort.
Second thing -- I'm not sure how much efficiency I'm losing by reading the webcam using gem and then converting to gridflow. I ended up doing it that way because I simply could not get [#camera] to grab images at all. The #camera panel does identify the laptop's built-in webcam (BisonCam,_NB_Pro) but 'bang'ing a [#camera 0] only produces this error.
error: [#io.videodev in /dev/video0 0] inlet 0 method bang: alloc_image: ioctl VIDIOCGMBUF: Invalid argument
(Ubuntu Lucid (2.6.33-29-realtime), 64-bit, pd 0.42.5-extended, installed gridflow from the puredyne PPA https://launchpad.net/~puredyne-team/+archive/ppa/+files/gridflow_9.12-1%7Eppa1%7Elucid1_amd64.deb)
Beyond that, I don't know enough about what gridflow is doing under the hood to use it more efficiently. Any pointers?
Thanks,
James
http://www.pdpatchrepo.info/hurleur/labelling-to-osc-blur9.pd