Forums > Dev

jit.freenect.grab on 64 bit?

June 24, 2013 | 9:24 am

i am currently trying to update a patch of mine to 64 bit since i need more memory. and i am very badly missing the jit.freenect.grab external which only runs in 32 bit.

i asked the programmer, jean marc pelletier, directly and this was his reply:
"Hi, sorry, I don’t have any time to dedicate to this project anymore… It’s open source, so if some enterprising soul (wink, wink) wants to have a stab at re-compiling, that would be great."

now… since i never compiled anything myself i am wondering: might there be any ‘enterprising soul’ out there who is working on this?


July 16, 2013 | 2:43 pm

Hi Karl,

I’ve just updated the old project to the max6 sdk, and compiled a 64+32bit external.
It loads fine in both 32bit and 64bit flavors of max, but at the moment I don’t have a kinect here to test and don’t know if it actually works.

It’d be great if you’d have a moment to give it a try.
In case it doesn’t load, please copypaste the contents of the max window so I can see what’s going on.
In case it loads but doesn’t work properly please try to describe what’s happening.

Hope you’ll have some fun with it!


July 17, 2013 | 1:57 pm

i’m a little bit in a hurry but this is tremendously cool you are at this! thank you so much!!!
i tried to load it into max running at 32 bit and 64 bit but it doesn’t load yet, see the output of the max window below (i think the error message is the same for both versions).

32 bit:
jit.freenect.grab: unable to load object bundle executable
2013-07-17 22:51:24.271 Max[726:c07] Error loading /Applications/Max 6.1/Cycling ’74/jitter-externals/jit.freenect.grab.mxo/Contents/MacOS/jit.freenect.grab: dlopen(/Applications/Max 6.1/Cycling ’74/jitter-externals/jit.freenect.grab.mxo/Contents/MacOS/j
it.freenect.grab, 262): Library not loaded: /Developer/jitfreenect64/libfreenect/build/lib/libfreenect.0.1.dylib
Referenced from: /Applications/Max 6.1/Cycling ’74/jitter-externals/jit.freenect.grab.mxo/Contents/MacOS/jit.freenect.grab
Reason: image not found

64 bit:
jit.freenect.grab: unable to load object bundle executable
2013-07-17 22:52:45.943 Max[734:c07] Error loading /Applications/Max 6.1/Cycling ’74/jitter-externals/jit.freenect.grab.mxo/Contents/MacOS/jit.freenect.grab: dlopen(/Applications/Max 6.1/Cycling ’74/jitter-externals/jit.freenect.grab.mxo/Contents/MacOS/j
it.freenect.grab, 262): Library not loaded: /Developer/jitfreenect64/libfreenect/build/lib/libfreenect.0.1.dylib
Referenced from: /Applications/Max 6.1/Cycling ’74/jitter-externals/jit.freenect.grab.mxo/Contents/MacOS/jit.freenect.grab
Reason: image not found

July 17, 2013 | 2:02 pm

p.s. the error does not occur on load but as soon as you make an instance of jit.freenect.grab and this instance is as well beige (like it is with nonexisting commands)

July 17, 2013 | 2:25 pm

Aha, thanks for the report, it’s my bad – the external is not statically linked to libfreenect so it would only work if you have it preinstalled.
I’ll look into it tomorrow, but if you need it urgently and don’t mind compiling you can follow the install instructions at:


July 18, 2013 | 10:05 am

Allright, here’s the statically linked version, it works on both 32/64 bit versions. This is the last version in the main branch, one by Jean-Marc and it still has some quirks.

I’ve been working on this external now and then, with bugfixes and some new features – I hope to polish it up in the following few weeks and release it, so check this space for updates:)

Thanks for testing!

April 2, 2014 | 12:03 pm

I basically duplicated your efforts, but here’s a git repo with the same thing. This is a 64-bit-only build.
see the release page for .mxo download:
or the git page for src:

August 8, 2015 | 4:13 pm

hi derp and nesa,
I noticed that nesa’s version has a @aligndepth attribute which is very useful —

@nesa, do you have the source for your version on github somewhere?
and/or @derp, do you have plans to add the @aligndepth attribute in your version?

thank you both for your work on this!

August 12, 2015 | 3:44 am

Hi Rama,

I was one of the original developers of the jit.freenect.grab, and you can always find the sources on my github fork:

Derp’s version was cool, but it is only 64bit – mine is universal.

The initial version of the project was a hacky mess, hell to compile. This one should be much easier.

All the paths are set through .xcconfig – nothing should be changed in the project settings directly. The xcode project is a modified example from max sdk, and I removed all the unnecessary references to libusb/libfreenect sources in the project itself.

the configuration file expects to have the libusb and libfreenect one folder up from the jit.freenect.grab source, but it’s easy to edit this to fit different setup.
libusb and libfreenect also have to be compiled as both 32 and 64 bit as well. Let me know if you need some help on setting this up(by default they compile for one architecture as far as I remember).

the external is (should at least) build with statically linked version of libfreenect and it should be self-contained.

32 and 64 bit, max 6 and 7 tested.

alighdepth is there as well.

I’ve attached the bare compiled external as well, but some work has to be done on helpfile and maybe packaging it properly – hope someone would be up to help with that?

Rama, please let me know if you run into any issues with compiling and running, I’m really eager to fix the project properly so we can concentrate on the bugs&features.

Best wishes,

August 12, 2015 | 10:57 am

hi nesa,
thanks! this looks great — and with cleaner library linking than the other version I was looking at. I’ll see if I can compile it sometime soon, and let you know how it goes. I can take a look at the help patch etc. also.

very happy to hear the project is still active!

January 11, 2016 | 7:30 am

Hi, thanks for this. I’m really tying to make the 64version to work but no luck.. I’ve tried both versions (derp mcderpington and NESA) .
Could some please give a step by step guide ? Thanks.

January 12, 2016 | 3:35 am

Hi Anton,

It should just work as any max external – just place it in the max search folder and it should load.
Please make sure that you are using the version I posted above, and that other versions are not loaded accidentally.

If it still doesn’t work for you, do you see something printed in Max window? What is your OS version?


January 13, 2016 | 6:27 am

Hi Nesa,
Thanks for your quick response. I am using Mac OS X 10.10.3 . The second outlet is working but the first (depth map) is not, and that what I need basically. The error I get is "float32: bad number" , when I try to change the float is crashes. Any clue ?
Anton v.
Edit: Ok, after deleting the help file it working properly. :) Thanks !

January 28, 2016 | 9:42 am

heyo Nesa + Brian.

I’m using Nesa’s most recent version with a MacBook Pro (Retina, 15-inch, Late 2013), OS X 10.11.3 and Max 7.1.0.

Using the data type declaration on object instantiation results in an error in the Max window- "float32: bad number" etc when Max opens in 32-bit mode.

No matter how the object is instantiated or in what mode it launches, changing the @mode attribute has no effect whatsoever on the values coming out of the first outlet. I can see with jit.cellblock that there are real depth numbers, though, and placing a jit.normalize between the first outlet and a window results in visible data.

Can you confirm? Is there any other data I can provide to help diagnose the issue?

January 28, 2016 | 9:49 am

Please also note that if one of you compiles a version where the @mode attribute switch works properly, I’ll update the helpfile to be m7-friendly. Maybe even put it into package form, as an exercise. Thanks in advance!

January 31, 2016 | 3:38 pm

Hello Joshua,

"float32 bad number" error is either due to old version of the external or the wrong object arguments.
can you please tell me:

a) what is printed in the max window when the object is loaded(build date/time)
b) how do you instantiate the object? Proper way would be:
jit.freenect.grab 1 float32/long

If you omit 1 for the planecount then the object tries to interpret the float32/long symbol as a number and fails. I guess planecount req is useless so I’m gonna remove it soon.

Also please note that if the output type is long then mode 1 is the same as mode 0 – there is no normalized output for non-float matrices.
It might be cool to add a normalized output for char type at some point). Feel free to add any feature requests of bug reports on the github page as well:

that’s where the freshest binaries&sources are as well.

Viewing 16 posts - 1 through 16 (of 16 total)

Forums > Dev