[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.
-Jonathan
>
More information about the Pd-list
mailing list