[PD] wiimote report

[Ivica Ico Bukvic]

> I can easily test this at the next rehearsal. But I think the more important
> question is whether that would make any difference. In other words, are
> the wiimote maintainers interested in merging disis_wiimote functionality.

OK, so studied the wiimote structure and decided to adopt its output model for disis_wiimote to streamline interoperability between the two. This means I adopted dynamic number of wiimotes, removed reliance on cwiid_internal.h, and included single data outlet model with prepended descriptors. I added also multidongle operation even though I did not test it.

I did test 3 wiimotes connected to the same computer (single bluetooth interface--I think there was a scientific research done a while ago that said up to 8 of them can be done reliably on a single bt interface, but that of course in part depends on the quality of the said interface) and will test 6 later tonight. So far no audio dropouts (other than when connecting a wiimote due to the way cwiid is structured) even when using rumble/settled options (those are the ones that cause most problems anyhow).

You can try new disis_wiimote from the L2Ork's software page.
It does rely on the latest cwiid git snapshot which is also mirrored on the page below:

http://l2ork.music.vt.edu/main/?page_id=56

One curious thing is that it appears that cwiid can only do 2 continuous streams (accelerometer + expansion, accelerometer + ir, or ir + expansion, never all three; buttons always work). I saw that someone did try to enqueue messages in the other version of wiimote external but that should have no effect as this is something that comes from cwiid and I suspect it is the way how hardware works... I did contact the original cwiid dev to hear their thoughts and am awaiting his response. In the meantime, if anyone has any thoughts on this I would love to hear them.

Cheers!