[PD] wiimote report

[Ivica Ico Bukvic]

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

> 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