jit.freenect.grab on 64 bit?

    Jun 24 2013 | 4:24 pm
    hello, 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?
    best k

    • Jul 16 2013 | 9: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!
      Cheers, nesa
    • Jul 17 2013 | 8:57 pm
      hey, 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). best k
      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
    • Jul 17 2013 | 9: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) k
    • Jul 17 2013 | 9: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: https://github.com/OpenKinect/libfreenect
      cheers, nesa
    • Jul 18 2013 | 5:05 pm
      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! nesa
    • Apr 02 2014 | 7: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:https://github.com/brianchasalow/jit.freenect.grab-64-bit/releases or the git page for src:https://github.com/brianchasalow/jit.freenect.grab-64-bit
    • Aug 08 2015 | 11: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! cheers, rama
    • Aug 12 2015 | 10: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, nesa
    • Aug 12 2015 | 5:57 pm
      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! cheers, rama
    • Jan 11 2016 | 3:30 pm
      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.
    • Jan 12 2016 | 11: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?
      cheers, nesa
    • Jan 13 2016 | 2:27 pm
      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 ? Thanks, Anton v. Edit: Ok, after deleting the help file it working properly. :) Thanks !
    • Jan 28 2016 | 5:42 pm
      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?
    • Jan 28 2016 | 5:49 pm
      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!
    • Jan 31 2016 | 11: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.
    • Feb 15 2016 | 8:15 pm
      Hey Nesa,
      Glad to see you keeping this alive! Just a quick report for you, using the latest from GitHub:
      -- on my machine, a 2015 MBP running 10.10, latest Max, I only get depth output if I set it to float64. float32 gives nothing, and long crashes. -- fwiw, aligndepth is not working, but I'm not sure if it is supposed to be -- I have contradictory helpfiles. -- it almost inevitably crashes Max when I close the window, even if I close it & turn off the qmetro....Let me know if you want it, & I'll send a crash report.
      Great to see it keeping alive, though -- thanks for all your work!
    • Feb 16 2016 | 8:22 pm
      Hi Matt,
      thanks for the nice bug report - I can reproduce most of it. Unfortunately I'm leaving for a bit longer vacation now and won't be able to fix the bugs until I return, bummer!
      -- I couldn't reproduce type long crash, so if you can send me a crash report about that it would be cool. -- float32 can repro, looks like I made a mistake in lookup table generation for float32. -- aligndepth: at the moment you'd need to close and open device to make it work. However it seems that the values coming out are not right, so this needs more work! Looking at the libfreenect code it appears that in aligndepth mode the library outputs only mm values, so in next version I'll remove alignmode attrib and add new mode value for depth in mm aligned to color. It might also need a small adjustment in lookup table generator. -- crash on close: I can repro this one, gotta hunt down the cause when I return.
      Btw, I also need to make an icon for a package manager - if anyone has a suggestion or wants to make one post it here please:)
    • Apr 07 2017 | 12:41 pm
      Any update on this?
    • Mar 14 2019 | 1:12 pm
      Thank you so much for these updates! I've been banging my head against a wall figuring out why the alpha version wasn't working...
    • Nov 20 2019 | 10:18 am
      I'm using Nesa's version (https://github.com/npnp/jit.freenect.grab), thanks Nesa. I can get the RGB data but not the depth data from it. There is no error messages, the window is just white. Mac OS X 10.13.6 Max 7 64bit, Max 8 64bit Xbox kinect 1414
      Any help?
    • Apr 17 2020 | 9:56 pm
      Can confirm that none of these jit.freenect.grab externals work in Max 8.1.2 or Max 7.3.6 in OSX 10.14.6 They all show up as orange.
    • Apr 21 2020 | 2:21 pm
      Are there any plans to update this for Max 8 and/or OSX 10.15?
    • Apr 23 2020 | 4:16 pm
      Hello, there are no plans on my side to update it any further, sorry for the inconvenience. If someone else wants to take over, I'd be happy to help.
    • Apr 23 2020 | 6:11 pm
      graham just posted about this over here and I just confirmed that his experimental "freenect" external (download here, unzip, place in packages folder) works out of the box with a Kinect 1 on Mac.
      if you're on mac 10.15, you'll first have to remove the quarantine attr as described here, e.g. : cd "~/Documents/Max 8/Packages/Max_Worldmaking_Package-devel" xattr -d -r com.apple.quarantine *
    • Apr 23 2020 | 6:36 pm
      Thanks Rob for checking this out (and for the magic incantation for 10.14!) -- it's hard to keep on top of this with lockdown + job + homeschooling...
    • Apr 26 2020 | 12:07 am
      Amazing, thank you Rob and Graham!
    • Sep 19 2020 | 4:56 pm
      Hello, That's a great joy, however I'm not able to load [freenect.mxo] in Max 8. Is it due to my old OSX11.6 El Capitan version or what am missing ?
      Also I've tryed the quarantine trick in terminal ...
      Any advice would be nice to go further.
      freenect: unable to load object bundle executable 2020-09-19 18:44:24.807 Max[27689:234171] Error loading /Users/dg/Documents/Max 8/Packages/Max_Worldmaking_Package-devel/externals/freenect.mxo/Contents/MacOS/freenect: dlopen(/Users/dg/Documents/Max 8/Packages/Max_Worldmaking_Package-devel/externals/fre enect.mxo/Contents/MacOS/freenect, 262): Symbol not found: _clock_gettime Referenced from: /Users/dg/Documents/Max 8/Packages/Max_Worldmaking_Package-devel/externals/freenect.mxo/Contents/MacOS/freenect Expected in: /usr/lib/libSystem.B.dylib in /Users/dg/Documents/Max 8/Packages/Max_Worldmaking_Package-devel/externals/freenect.mxo/Contents/MacOS/freenect
    • Sep 19 2020 | 5:05 pm
      This compilation works with Max 8 64 bit under Catalina. I'm not sure about El Capitan.
    • Sep 19 2020 | 5:13 pm
      Wo! Thank you so much . That is working fine. OSX 10 11.6 / Max 8.1.5 I going to update this work Please where are the sources or link for this version ?
    • Sep 20 2020 | 4:38 pm
      All freenects are shaped after original code by Jean-Marc Pelletier (https://jmpelletier.com/freenect/). I experimented with Pelletier's source code years ago. My modified source files are long gone with old laptop. However I'm not sure if this particular compilation is really my own or it is one of versions circulating on the forum and compiled by someone else.
    • Sep 20 2020 | 5:33 pm
      Yes I know there are lot of compilation tries from pelletier's code. Don't mind, thanks it works just fine here.