[PD] wiimote report

[Ivica Ico Bukvic]

On 02/17/2012 01:27 PM, Roman Haefeli wrote:
> On Fri, 2012-02-17 at 11:31 -0500, Ivica Ico Bukvic wrote:
>>> I just tested that with the [wiimote] from pd-svn and it seems I can
>>> have three continuous streams going at the same time (though the
>>> update
>>> rate seems to lower). I enabled accelerometers, IR and motionplus and
>>> got updates on all three. Is it really a limitation by cwiid, then?
>>>
>>> Roman
>> Cwiid demos (e.g. wmgui) exhibit the same limit of 2 streams which suggests it is indeed a problem with cwiid. To clarify my observation, while you do get "updates" on all three, one of them is frozen (does not change values but just outputs the same over and over).
> Again, this is not the case with [wiimote]. I tested the following
> setups:
>
> * accelerometers, IR, motionplus
> * accelerometers, IR, classic controller
>
> All three sensors are updated frequently (I was wrong when I claimed it
> got significantly slower; this was due to having the Pd GUI be shown in
> a VNC session).
>
> This doesn't work:
>
> * accelerometers, motionplus, classic controller
>
> It seems, you cannot use two extensions at the same time. It's either
> motionplus or classic controller, but not both at the same time.
>
> Note: This is with 0.6.00+svn201 (in Ubuntu 11.04), probably this
> matters? AFAICT, [wiimote] from svn does _not_ use a local version of
> cwiid.h.
>
> Another note: I experience the same behaviour with wmgui: It only lets
> me display two stream simultaneously and it lacks a section for
> motionplus.
>
> Roman

OK, I finally figured it out. It seems that the RPT_EXT call is not 
working properly any more as it invokes all known extensions and this 
results in failed enabling of the extension. OTOH if one explicitly 
enables external they wish to use (eg. RPT_NUNCHUK), then all is well... 
I just fixed this in the disis_wiimote.

That said, after further study of wiimote.c I would conclude it has 
progressed considerably since I last checked it and it poses code 
legibility advantages over disis_wiimote. Where it still falls short is 
it causes unnecessary xruns when sending changes to the report mode, 
setLED and setRumble, particularly on weaker cpus (e.g. atom netbooks), 
even if using a real-time kernel. It would be therefore perhaps a good 
idea if someone considered merging disis_wiimote's threaded design plus 
its ability to be driven by a metro, rather than outputting data as 
quickly as possible (which seems in many cases unnecessary and may 
result in redundant ways of slowing down such a stream, e.g. using 
speedlim kinds of workarounds).

Cheers!

>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->  http://lists.puredata.info/listinfo/pd-list


-- 
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound&  Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Director, CCTAD
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net