----- 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