Kinect, Glitches, and Reading Carefully
So I bought my own Kinect. This is after months of having one around the place and telling myself I’d get down to some serious fooling around with it tomorrow. Always tomorrow. But the loan (and the relationship) ended so I bit the bullet, bought my own used one. Having some filthy lucre invested in it is pretty good motivation to fool with it in earnest thus far.
But… I bought the thing used. I’ve bought a lot of electronic junk at garage sales and ended up scrap plastic and metal for my trouble so my skepticism level is already up there. So when I hooked it up to Processing and saw a swath of static scrolling up and down through the IR output…
Curses.
Googling around didn’t turn up much so I resolved to make my first project be a diagnostic tool to figure out if the info was really coming in or if it was simply a display issue on the part of the Processing sketch I was using. Deadline: before the return/exchange period expires on this beast.
Long story short, I got the basic flow of things down, learned a bit more about the various Kinect libraries for OpenFrameworks, Processing, Cinder, and otherwise but never whipped up a working diagnostic. Work was halted on that tool when I came across this:
Yep. It’s a glitch in the sketch, not my sensor. So if you’re pulling your hair out troubleshooting the IR sensor on the Kinect, try it in open Frameworks or one of the various 3d scanning programs and see if it messes with you.
On to the next project with it: whipping up a Kinect-based control scheme that’ll work with the classic flying shoot ’em up Terminal Velocity. Basically, I want to wiggle around with my arms out like I’m the plane, headbanging to blow up tanks. Because that’s what we all want. This will probably involve actually knowing what I’m doing with OSC instead of merely nodding and saying “ahh, yeah, OSC” when someone mentions it.