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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list