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