Yeah, no doubt that disis-wiimote has been well tested. I'm just highlighting different cases. I know a couple projects that needed 6 wiimotes connected to 1 computer, where I think L2Ork does one wiimote per computer. Now, it would be good to rely on a single object to handle all cases.
Good point. We only did as many as 2 per computer. Then again, I cannot imagine why more would not work other than hardware/driver limitations that have nothing to do with the external.
Just to illustrate this point, pd-l2ork is based on Pd-extended, which includes the work of over 100 people. Any of those chunks of work would be much less valuable without the rest. There is additional work just to make all those chunks of work into one, of course.
Indeed. Some of those chunks are my own spread across Pd, Gem, and other externals.
Please don't get me wrong, I would love to see all these changes integrated into one uniform package but the key stepping stone to this is that pd/extended (unlike pd-l2ork) is trying too hard to maintain binary compatibility. I see no benefit in that when the core design is still a moving target. Besides, some of the early architectural choices have been undoubtedly less than optimal as it was difficult if not impossible to anticipate ways pd would evolve and yet they to this day continue to hamper progress. This is why pd-l2ork can do things that pd or pd-extended cannot without *major* code rewrites. Of course, major code rewrite is the ideal way but also one that is very unlikely to happen unless someone is paid to do just that for a year or two (which again is not the most likely thing). So, iterative improvements seem to me the most plausible way for a project like Pd to move forward and that is exactly what I am doing. However, due to the core difference in opinion as to how this should be approached (namely binary compatibility) makes merging pd-l2ork and pd/extended difficult if not impossible without considerable adaptations to the patches themselves and/or architectural choices. For me to spend time on those differences or worse yet guess what those architectural choices might mean to Miller or you would be just as inefficient as it was early on when I was submitting patches upstream. And this is why I leave such decisions/merging efforts to Miller and you.
Best wishes,
Ico
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Hans-Christoph Steiner' hans@at.or.at Cc: 'pd-list' pd-list@iem.at Sent: Sunday, February 12, 2012 12:45 PM Subject: Re: [PD] wiimote report
Yeah, no doubt that disis-wiimote has been well tested. I'm just highlighting different cases. I know a couple projects that needed 6 wiimotes connected to 1 computer, where I think L2Ork does one wiimote per computer. Now, it would be good to rely on a single object to handle all cases.
Good point. We only did as many as 2 per computer. Then again, I cannot imagine why more would not work other than hardware/driver limitations that have nothing to do with the external.
I thought I saw a comment in your code that said it only handled one controller.
-Jonathan
Just to illustrate this point, pd-l2ork is based on Pd-extended, which includes the work of over 100 people. Any of those chunks of work would be much less valuable without the rest. There is additional work just to make all those chunks of work into one, of course.
Indeed. Some of those chunks are my own spread across Pd, Gem, and other externals.
Please don't get me wrong, I would love to see all these changes integrated into one uniform package but the key stepping stone to this is that pd/extended (unlike pd-l2ork) is trying too hard to maintain binary compatibility. I see no benefit in that when the core design is still a moving target. Besides, some of the early architectural choices have been undoubtedly less than optimal as it was difficult if not impossible to anticipate ways pd would evolve and yet they to this day continue to hamper progress. This is why pd-l2ork can do things that pd or pd-extended cannot without *major* code rewrites. Of course, major code rewrite is the ideal way but also one that is very unlikely to happen unless someone is paid to do just that for a year or two (which again is not the most likely thing). So, iterative improvements seem to me the most plausible way for a project like Pd to move forward and that is exactly what I am doing. However, due to the core difference in opinion as to how this should be approached (namely binary compatibility) makes merging pd-l2ork and pd/extended difficult if not impossible without considerable adaptations to the patches themselves and/or architectural choices. For me to spend time on those differences or worse yet guess what those architectural choices might mean to Miller or you would be just as inefficient as it was early on when I was submitting patches upstream. And this is why I leave such decisions/merging efforts to Miller and you.
Best wishes,
Ico
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I thought I saw a comment in your code that said it only handled one controller.
-Jonathan
It's been a while since I edited the source and/or tested more than one wiimote per computer. It may be just a leftover comment. Also, I think this is in part because each wiimote would have its own instance (one wiimote object per connection, which makes sense from the visual perspective). Let me investigate and I'll let you know...
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Ivica Ico Bukvic Sent: Sunday, February 12, 2012 2:00 PM To: 'Jonathan Wilkes'; 'Hans-Christoph Steiner' Cc: 'pd-list' Subject: Re: [PD] wiimote report
I thought I saw a comment in your code that said it only handled one controller.
-Jonathan
It's been a while since I edited the source and/or tested more than one wiimote per computer. It may be just a leftover comment. Also, I think this is in part because each wiimote would have its own instance (one wiimote object per connection, which makes sense from the visual perspective). Let me investigate and I'll let you know...
Just checked the code and it seems at some point I hardwired it to only one wiimote at a time. I changed a MAXWIIMOTES define to support up to 16 (which is a completely arbitrary number I haven't tested), recompiled it, and it connected 2 without problems. I suspect it will connect many more before hardware/drivers gives out...
Best wishes,
Ico
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Jonathan Wilkes' jancsika@yahoo.com; 'Hans-Christoph Steiner' hans@at.or.at Cc: 'pd-list' pd-list@iem.at Sent: Sunday, February 12, 2012 2:27 PM Subject: RE: [PD] wiimote report
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Ivica Ico Bukvic Sent: Sunday, February 12, 2012 2:00 PM To: 'Jonathan Wilkes'; 'Hans-Christoph Steiner' Cc: 'pd-list' Subject: Re: [PD] wiimote report
I thought I saw a comment in your code that said it only handled one controller.
-Jonathan
It's been a while since I edited the source and/or tested more than one wiimote per computer. It may be just a leftover comment. Also, I think this is in part because each wiimote would have its own instance (one wiimote object per connection, which makes sense from the visual perspective). Let me investigate and I'll let you know...
Just checked the code and it seems at some point I hardwired it to only one wiimote at a time. I changed a MAXWIIMOTES define to support up to 16 (which is a completely arbitrary number I haven't tested), recompiled it, and it connected 2 without problems. I suspect it will connect many more before hardware/drivers gives out...
Cool. I guess the other question is this: does the threading stuff in your class solve a problem with dropouts that still exists in the other wiimote class? Can you put together a demo patch that would cause dropouts on the old wiimote class before you revised it, but which doesn't cause dropouts in your revised wiimote class? Then someone using the other wiimote class can test to see if they get dropouts. (Unfortunately I don't have a wiimote so I can't test.)
Also, could the person who has six wiimotes test with Ivica's class and see if there are dropouts?
-Jonathan
Best wishes,
Ico
Cool. I guess the other question is this: does the threading stuff in your class solve a problem with dropouts that still exists in the other wiimote class? Can you put together a demo patch that would cause dropouts on the old wiimote class before you revised it, but which doesn't cause dropouts in your revised wiimote class? Then someone using the other wiimote class can test to see if they get dropouts. (Unfortunately I don't have a wiimote so I can't test.)
I can guarantee there are no dropouts since this is what L2Ork does at all times. disis_wiimote always runs in the same pd instance as the audio parts and does not require clumsy things like two instances of pd running concurrently. This is because elements that may cause dropouts (namely things that are sent back to wiimote, like rumble and LED; rumble is used extensively in L2Ork) are run in a separate thread. So, the only time you could potentially get dropouts is if the patch has maxed out cpu which is an entirely different issue...
Also, could the person who has six wiimotes test with Ivica's class and see if there are dropouts?
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.
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Jonathan Wilkes' jancsika@yahoo.com; 'Hans-Christoph Steiner' hans@at.or.at Cc: 'pd-list' pd-list@iem.at Sent: Sunday, February 12, 2012 3:59 PM Subject: RE: [PD] wiimote report
Cool. I guess the other question is this: does the threading stuff in your class solve a problem with dropouts that still exists in the other wiimote class? Can you put together a demo patch that would cause dropouts on the old wiimote class before you revised it, but which doesn't cause dropouts in your revised
wiimote
class? Then someone using the other wiimote class can test to see if they get dropouts. (Unfortunately I don't have a wiimote so I can't test.)
I can guarantee there are no dropouts since this is what L2Ork does at all times. disis_wiimote always runs in the same pd instance as the audio parts and does not require clumsy things like two instances of pd running concurrently. This is because elements that may cause dropouts (namely things that are sent back to wiimote, like rumble and LED; rumble is used extensively in L2Ork) are run in a separate thread. So, the only time you could potentially get dropouts is if the patch has maxed out cpu which is an entirely different issue...
Also, could the person who has six wiimotes test with Ivica's class and
see
if there are dropouts?
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.
Well, if you test it with 6 and it works, and you are preventing dropouts that can/do happen with the other class, then people can recommend using your class over the other one.
-Jonathan
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!
On Thu, 2012-02-16 at 15:09 -0500, Ivica Ico Bukvic wrote:
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.
So, I just tested the system with 4 wiimotes and it worked without any xruns. I could not connect the 5th one not because of Pd but rather limitations of the bluetooth chip in a netbook. I suspect a better computer would allow for more connections and/or use of 2 bluetooth dongles...
Hope this helps!
On Thu, 2012-02-16 at 15:09 -0500, Ivica Ico Bukvic wrote:
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.
Nice. Personally, I prefer this design.
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.
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
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).
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
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
explicitly enables external they wish to use (eg. RPT_NUNCHUK), then all is well... I just fixed this in the
Ugh, too tired... that should've been "extension," not an "external"
last checked it and it poses code legibility advantages over disis_wiimote. Where it still falls short is
And that should've been "offers" instead of "poses"...
Apologies for dredging up old posts...
Did we ever get one good/merged [wiimote]?
Julian
On 04/09/2012 06:38 PM, Julian Brooks wrote:
Apologies for dredging up old posts...
Did we ever get one good/merged [wiimote]?
Julian
Funny you asked. I made several releases of disis_wiimote since, including making it output-compatible with vanilla wiimote. Also, the latest version 0.9.0 has a working passthrough mode (MotionPlus + Nunchuk at the same time). Documentation is still a bit basic regarding this one, but it is also fairly straightforward (basically requires an additional flag called togglePassthrough). This version requires custom L2Ork version of cwiid library (also downloadable from the l2ork site) which has a number of bug fixes and some fundamental changes to the way the code works. NB: this library is not backwards compatible. One of them includes complete auto-detection of extensions without having to deal with separate flags for each of the extensions (with the exception of the passthrough mode since that does some really unusual init things from the hardware perspective that have warranted an entirely new thread in libcwiid to deal with it). AFAIK this is currently the only FOSS implementation that gives you working passthrough support.
My hope is to submit cwiid changes upstream soon...
http://l2ork.music.vt.edu/main/?page_id=56
Cheers!
Very nice. As per usual many thanks for sharing. And really good to see the L2ork project steaming ahead.
All good wishes,
Julian
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Jonathan Wilkes' jancsika@yahoo.com; 'Hans-Christoph Steiner' hans@at.or.at Cc: 'pd-list' pd-list@iem.at Sent: Sunday, February 12, 2012 1:59 PM Subject: RE: [PD] wiimote report
I thought I saw a comment in your code that said it only handled one controller.
-Jonathan
It's been a while since I edited the source and/or tested more than one wiimote per computer. It may be just a leftover comment. Also, I think this is in part because each wiimote would have its own instance (one wiimote object per connection, which makes sense from the visual perspective). Let me investigate and I'll let you know...
Sounds good. If it turns out your class can handle the same number of wiimotes as the other wiimote class, are there any other functional differences that would warrant the existence of two wiimote classes?
-Jonathan
-
Ivica Ico Bukvic -
Jonathan Wilkes -
Julian Brooks -
Roman Haefeli