I’m failing now at doing something I’ve done multiple times before, and I’m not entirely sure what’s wrong.
Using a Mac Mini running 6.0.8 and 10.8.2 to get input via jit.freenect.grab from a Kinect. When the Kinect is plugged in, sending an open message is resulting in a crash. Switching machines to a mid-2011 MBP has the same result. So does switching USB ports and switching Kinects to a model bought on the same day. The error is always the same. Downgrading to the RC4 of jit.freenect.grab does not change anything. Synapse still works, as does Dale Phurrough’s sensational Mac port of jit.openni, but I am bound by two client strictures: we must use a mac, and we have to use two kinects to make this work (it’s a long lane that’s being tracked).
Did Microsoft go and alter the Kinect hardware without talking to anyone?
Has anyone had a similar experience? It’s especially galling because I did the exact same thing last month with no problems, but with 1 y.o. Kinect models….
This is the crashlog, which is the same on EVERY computer I use with these Kinects:
Process: Max 
Version: 6.0.8 [6f52750] (6.0.8)
Code Type: X86 (Native)
Parent Process: launchd 
User ID: 501
Date/Time: 2013-02-19 14:51:56.794 -0500
OS Version: Mac OS X 10.8.2 (12C60)
Report Version: 10
Interval Since Last Report: 246710 sec
Crashes Since Last Report: 8
Per-App Interval Since Last Report: 67167 sec
Per-App Crashes Since Last Report: 5
Anonymous UUID: 75078D2B-9982-F7BD-1A99-18D89461DA9C
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000000000005c
VM Regions Near 0x5c:
–> __PAGEZERO 0000000000000000-0000000000001000 [ 4K] —/— SM=NUL /Applications/Max6/Max.app/Contents/MacOS/Max
__TEXT 0000000000001000-0000000000676000 [ 6612K] rwx/rwx SM=COW /Applications/Max6/Max.app/Contents/MacOS/Max
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.jmp.jit.freenect.grab 0x06e803ca freenect_set_depth_callback + 9
1 com.jmp.jit.freenect.grab 0x06e787fc jit_freenect_grab_open + 517
2 com.cycling74.Max 0x000b8aa5 object_method + 963
3 com.cycling74.MaxAPI 0x04dc533b object_method + 139
4 com.cycling74.JitterAPI 0x0e9ff474 jit_object_method + 118
5 com.cycling74.JitterAPI 0x0ea1d517 max_jit_gimme_method + 69
6 com.cycling74.Max 0x000261cc typedmess_fun + 1050
7 com.cycling74.Max 0x0006c41c outlet_anything + 846
8 com.cycling74.Max 0x000261cc typedmess_fun + 1050
9 com.cycling74.Max 0×00026581 typedmess + 72
10 com.cycling74.Max 0×00027577 aeval + 1288
11 com.cycling74.Max 0x000102d9 atombuf_eval + 145
12 com.cycling74.MaxAPI 0x04dc3594 atombuf_eval + 84
13 com.cycling74.message 0x13b86753 jmessage_atombuf_eval + 339
14 com.cycling74.message 0x13b86e30 jmessage_dobang + 123
15 com.cycling74.message 0x13b86f05 jmessage_mousedown + 205
16 com.cycling74.Max 0x000b8aa5 object_method + 963
17 com.cycling74.Max 0x000fd194 BoxComponent::sendMouseMessage(juce::MouseEvent const&, symbol*, double, double) + 264
18 com.cycling74.Max 0×00101457 BoxComponent::mouseDown(juce::MouseEvent const&) + 1247
19 com.cycling74.Max 0×00330410 juce::Component::internalMouseDown(juce::MouseInputSource&, juce::Point
const&, juce::Time const&) + 584
20 com.cycling74.Max 0x0038e392 juce::MouseInputSourceInternal::sendMouseDown(juce::Component*, juce::Point
const&, long long) + 96
21 com.cycling74.Max 0x0038ea38 juce::MouseInputSourceInternal::setButtons(juce::Point
const&, long long, juce::ModifierKeys const&) + 380
22 com.cycling74.Max 0x0038eb74 juce::MouseInputSourceInternal::handleEvent(juce::ComponentPeer*, juce::Point
const&, long long, juce::ModifierKeys const&) + 172
23 com.cycling74.Max 0x0038dc45 juce::MouseInputSource::handleEvent(juce::ComponentPeer*, juce::Point
const&, long long, juce::ModifierKeys const&) + 75
24 com.cycling74.Max 0×00396289 juce::ComponentPeer::handleMouseEvent(int, juce::Point
const&, juce::ModifierKeys const&, long long) + 103
25 com.cycling74.Max 0x004362df juce::NSViewComponentPeer::sendMouseEvent(NSEvent*) + 113
26 com.cycling74.Max 0×00436599 juce::NSViewComponentPeer::redirectMouseDown(NSEvent*) + 129
27 com.cycling74.Max 0x0042b9f3 -[JuceNSView_1_52_105_3 asyncMouseDown:] + 34
28 com.cycling74.Max 0x0042eade -[JuceNSView_1_52_105_3 mouseDown:] + 52
29 com.apple.AppKit 0x97b1da21 -[NSWindow sendEvent:] + 6968
30 com.apple.AppKit 0x97b18a0f -[NSApplication sendEvent:] + 4278
31 com.apple.AppKit 0x97a3272c -[NSApplication run] + 951
32 com.cycling74.Max 0x0043270f juce::MessageManager::runDispatchLoop() + 731
33 com.cycling74.Max 0x002c1f02 juce::JUCEApplication::main(juce::StringArray const&) + 68
34 com.cycling74.Max 0x002c2025 juce::JUCEApplication::main(int, char const**) + 73
35 com.cycling74.Max 0x0000db8b _start + 209
36 com.cycling74.Max 0x0000dab9 start + 41
FYI, the serial #s for the kinects in question are:
167765324135 and 060706224435.
I’m frequently quite dense, and I’m kind of hoping that this is the case here. Any help would be appreciated. Yes, I’ve gently asked Jean-Marc, but he’s busy with other things right now.
hey, i had a crash the other day with jit.freenect.grab as well, and contacted Jean-Marc Pelletier too. No idea if this is related ; still i use jit.openni, which is far more complicated to install, but seems to work without problem for me. I did obtain that kinect very recently, it’s an xBox model, fwiw.
what is the problem with jit.openni ? does it not work well on osx ? can’t you use 2 kinects at the same time ?
as far as i can tell, you cannot use more than 1 kinect with the mac version of jit.openni. if i’m wrong it will be a relief.
oh, and i was able to successfully install jit.openni and make it work on these same machines. it’s only jit.freenect.grab that’s giving me guff.
An update: I suspect MS may have altered the innards of the Kinect. Confirmed that everything is totally fine with my older model (serial # 011227103635). I’m going to reach out to the libfreenect folks and see if they can replicate.
cool, i did think you could handle several kinects with jit.openni though… i would help if i could, but am not very good with the sources.
OK, here’s the deal: jit.freenect.grab as of version RC5 does not work with the new model of Kinects. You can tell the model number by looking at the bottom of the unit, at the upper right corner of the sticker underneath. If it says "model 1414" you can use the object. If it says "model 1473" then you should return it if you wish to work with multiple depth images on a Macintosh at this time. Should I learn that Dale has updated the mac version of jit.openni to provide this functionality, or that Jean-Marc has updated jit.freenect.grab, I’ll try to remember to update this thread.
thanks for the reporting joshua!
Any news on this ?
I have the same problem
Good to hear that jit.openni works on all the models. I do hear and respect the desire for multiple Kinect support on it.
I’ve read sporadic posts via google that with some C hacking they were able to use OpenNI and SensorKinect on 2 Kinects. So it may be possible to enhance jit.openni to use this same realm of hacks.
Its a time/priority thing for me. I don’t have the extra time to do the solo research and coding changes. What *is* possible is for anyone to enhance the code at https://github.com/diablodale/jit.openni. Its all up there. I could perhaps collaborate with someone and then merge back in the changes for which everyone to benefit.
I’m not able to use jit.openni with the new model kinect 1473
Does anyone on mac can use it ?
I read about a partial support of the new model from libfreenect but i have to try yet
vichug above reported jit.openni did work with the new 1473 hardware. Did I misread that post?
If there is an issue with that hardware, it will be due to be a limitation of SensorKinect. SensorKinect is the hardware driver which exposes the Kinect hardware to OpenNI. The most recent version of SensorKinect v0.93 has only preliminary support for the Kinect for Windows hardware. It could be possible that a yet newer version of Kinect hardware (e.g. 1473) is not yet supported. https://github.com/avin2/SensorKinect
** It is open source. What dev wants to volunteer, fork it, make the updates, and then release an update for SensorKinect? **
All the software that doesn’t use the officlal Kinect SDK is experiencing failures including libfreenect, Synapse, ofxKinect, NIMate, OpenKinect, and ROS
I hope that soon, the devs which wrote the hardware drivers like SensorKinect (or other volunteers) can update the code to support the new hardware. It is this driver which is crucial. jit.openni is agnostic (doesn’t care) about the hardware, it works on Kinect, Xtion, PMD Camboard, etc. All you need is a working hardware driver.
hmm i forgot to check the version number of that kinekt, and i don’t have it under hands atm..; so sorry, i can’t really help.
was there any solution for the 1473 problem? or is the solution to return it?
i’m working with max 6.1.7 on a mac osx 10.9.2. i am using jit.openni, not freenect
Forums > Jitter