----- Original Message ----- > From: Ivica Ico Bukvic <i...@vt.edu> > To: 'Hans-Christoph Steiner' <h...@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 > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list