|
|
Kineme WiiMote Nunchuk support on the way? Hi, sorry for complaining in the previous post.... I just LOVE your wiimote patch, it is working as a charm.... However, i dunno if you guys own a WII and ever played Zelda or DBZ Budokai... these games are AMAZING, esp. the way to control, using both wiimote + nunchuck. I would really like to have the nunchuck avaiabiliy within your patch, and i was wondering why the feature was dropped ? Are you planning to add the nunchuck in the future, or will the patch stay as it is ? Thanks for taking the time to answer.... (and to mention the IR cap., i must say it also works a treat, tryied it on max msp) |
We had the nunchuk in some early beta versions, but it seems to cause some connectivity problems. Once I get around to cleaning it up so it's reliable, it'll be in there. It's on the table, don't worry. as you said, it is Amazing to play with :) If only it was reliable :/
I'll be working on Classic Controller support too, now that I got one to test with. :)
Thanks for the info. I'm eager to play with this fantastic controller. One nice addition would be gesture recognition / curve matching, to allow for ever more complex moves, "a la" AILive, the middleware for wiimote developpers. - but this is another big project, as there ain't no framework around (except a buggy one for MaxMsp by Ircam), to my knowledge, correct me if i'm wrong-
I branched Gesture Recognition into a separare feature request --- see http://kineme.net/FeatureRequests/GestureRecognition
Thanks, i didn't want to flood the feature request section.
While on the topic of functionality, how should we handle multiple remote patches mapping to multiple remotes? I'm thinking of adding inputs to the patch that allow user control of the LEDs as well as control of the rumble feature (and yes, eventually audio once that gets reverse engineered to a usable level.)
Should there be a special way to pick which remote goes to which patch?
Also, how will this work when Nunchuk, Classic Controller, Zapper, WiiFit Board, and all the other various add-ons get their own patches as well? I'd like for these to be separate so there isn't one monstrous patch with useless outputs (each extension device is mutually exclusive with all the others)
*One input on the main Wiimotepatch (int 0-->3) that would act as a priority order, 0 meaning that the patch connects to the first Wiimote that presses 1+2, and that assigns the corresponding LED , could be ok ?
*Separate patches for add-ons, with the same priority input.
*The rumble feature is a must have, too.
*The audio would mean that we have a audio folder patch to load a sound bank...
Anyway, i don't know if many ppl will need to have multiple wiimotes....
One Problem, Bluetooth (and the Wii itself I think) can actually support up to 7 devices... So we'll have to do some kind of hacking with the LEDs.
The priority idea makes perfect sense. I was thinking something along those lines, but thought of this problem: What if two patches are created with the same priority? I'm thinking I'll split the remote management part off into its own thread (this will hopefully fix several connection issues), and then have patches query this thread. One query can be a priority request, where they get assigned a different one if the requested one is already assigned. In this case, the patch should have some kind of output that corresponds to the assigned priority so they can plug it into the priority of the sub-patch (nunchuk, et al.) Does that make sense? Problems?
I agree, not many people will need multiple remote support. That doesn't mean it wouldn't be cool to have, just in case though :) (Think of the party patch potential!)
Yes, it makes sense to wire to extension patch to the main Wiimotepatch, so that the latter forwards its priority rank.
Party patch is thrilling ! What about a multiplayer 3D Tron-o-Pong controlled by wiimotes.... ?