It turns out it's not an easy thing. In order to poll the wiimote
you need to use a Carbon CFRunLoop. Since Max/MSP is a Carbon app
natively, the aka.wiiremote object can just tag onto the built-in
CFRunLoop to get events. Pd's Tcl/Tk process is a Carbon app, but
that's a separate process from 'pd'.
So after a fair amount of discussion with Apple engineers, it seems
that the only solution is to make a totally separate process (yes a
process, not just a thread) which runs the CFRunLoop to poll the
wiiremote. Then the Pd object will poll that process to get data
from it. This is not simple, but doable, hence the delay.
If only Nintendo had just made it a proper HID device, then it would
'just work' with [hid]. But they did something quite stupid, they
make it show up as if it was a proper HID device, but then it sends
custom, non-HID data packets. So the OS sees it as a HID device and
associates with it, but then can't understand the data from it. That
leaves the IOBluetooth API as only option, which is tied to Carbon
CFRunLoops.
The best solution would be if someone wrote a driver for it that
translated the custom data packets into HID, then it would 'just
work' with [hid]. Unfortunately, I am not a driver guy...
For now, this looks like a good option for using the wiiremote with
Pd on Mac OS X:
http://code.google.com/p/darwiinosc/
.hc
On Mar 21, 2008, at 8:44 AM, Luigi Rensinghoff wrote:
How is the Progress with the wiiremote external ??? (especially Mac- Intel)
I have played around with OSculator and its really working fine.
Anybody else playing around with the Wii ???
Happy Easter
Luigi
---------------------------------------<
Luigi Rensinghoff luigi.rensinghoff@freenet.de skype:gigischinke ichat:gigicarlo
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams