[PD] wiimote report

Jonathan Wilkes jancsika at yahoo.com
Sun Feb 12 23:49:22 CET 2012

----- Original Message -----
> From: Ivica Ico Bukvic <ico at vt.edu>
> To: 'Jonathan Wilkes' <jancsika at yahoo.com>; 'Hans-Christoph Steiner' <hans at at.or.at>
> Cc: 'pd-list' <pd-list at 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.



More information about the Pd-list mailing list