Is there any efficient way to record the skeleton data from kinect ?

Nov 3, 2011 at 2:00pm

Is there any efficient way to record the skeleton data from kinect ?

Is there any efficient way to record the position data of the skelton from kinect in max?

Could anyone share an example patch or show some hints?

Thank you so much..

Nov 3, 2011 at 8:35pm

Here’s what I use:

– Pasted Max Patch, click to expand. –
Nov 7, 2011 at 3:20pm

Thank you so much for sharing the idea and the patch.

Dec 1, 2011 at 12:41am

What are you using it for, just curious :)
Any patches to share? I am studying Max.

Dec 1, 2011 at 4:09pm

I’d recommend looking at seq~, since it’ll make it easier to replay the data. I haven’t done this, but am working on something similar and this sounds like it’d be perfect, since you can pause it mid stream, play it back slowly, etc.

Dec 1, 2011 at 6:16pm

the patch onar3d posts here:
…seems to go pretty far,… He is talking about CPU problems though (but the post is from two years ago)

You would have to use something like OSCeleton if you are using OpenNI drivers to get the OSC messages from the Kinect into Max

You can use this:
If you are using the Microsoft SDK drivers

Dec 1, 2011 at 10:04pm

Yeah, I’m wondering if his CPU problems might have anything to do with 32-bit resolution. If you’re trying to do it over an hour (which he was in his demo) it seems like 0-1 isn’t going to be a huge amount of range (since you have to parse it out over 158,760,000 samples); because it’s ticking over so slow, it’s entirely possible that he’s getting a lot of dupes? Haven’t tried his patch and don’t have anything to generate OSC handy, but I wouldn’t rule out seq~ on the basis of that, especially if it’s 64-bit friendly now and you’re not storing an hour’s worth of data at a go.

Also, it’s a question of how you pack your data. Store it as a list of points, rather than a collection of labelled values, and use zl change to thin your data.


You must be logged in to reply to this topic.