[PD] wiimote report

[Jonathan Wilkes]

----- Original Message -----

> From: Ivica Ico Bukvic <ico at vt.edu>
> To: 'Hans-Christoph Steiner' <hans at at.or.at>
> Cc: 'pd-list' <pd-list at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>