[PD] Mess and redundancy in the Pd eco system (was: [range] / [maxlib/scale] for audio)

[Roman Haefeli]

On Fre, 2015-06-05 at 14:32 -0300, Alexandre Torres Porres wrote:
> > I couldn't find a [range] object in Pd-extended.
> 
> 
> I have it in 0.42, maybe yours is 0.43 - it's located in flatspace,
> but it doesn't even have a help file...

Wow, you're missing so much new stuff... (and yes, I was checking
0.43-extended)

> Well, this all makes me say how I find Pd-extended to be very messy,
> with many redundanct objects, not to mention buggy or poorly
> documented (many have no help whatsoever). As I dig further, I just
> find more of all this... I know this directs this thread to another
> discussion, but I'd really hope for the update and maintenance active
> again, and that I could help cleaning some stuff up.

I _believe_ Pd-extended was meant to be collection of as much software
as was/is available for Pd. It respected the libraries (I'm sure this is
argued by some, regarding multi-object libs vs. single-object externals)
and put it into namespaces so that the user can decide what to use and
what not. One could also say it deferred the burden to deal with the
mess on the user. But it made much of the existing Pd ecosystem
available to the masses - which I consider a huge achievement - and you
can more or less assume that a patch made on platform Y will work the
same on platform X with the same version of Pd-extended.

I think tiding it all up is again a huge task. It's all free software,
so anyone could do it. Having followed this list for a few years, I
don't believe in the "authoritative" collection of Pd externals and
abstraction anymore. People are using software in different ways for
different purposes, and one can observe that many create their own nice
tidied-up unified collections of abstractions (mtl, rjlib, netpd, etc.)
and none of them gained so much traction that they would be used by a
majority of the Pd users. I even think that trying it would be a lost
game and would end up with endless mailing list debates.

Retrospectively, it looks like maintaining something like Pd-extended is
a too complex task to be distributed among many and too much for a
single person (Pd-L2ork being the counter example). I sense agreement on
the notion that effort is better spent on making separate libraries
easily accessible/distributable. People willing to help could focus on
the external they have the most interest in. It already started in
Debian, where IOhannes, Hans (mainly) and me (to some lesser degree)
worked on creating proper Debian packages of a lot of externals. Similar
could be done for other platforms, too. Pd-extended could be the
collection of those packages that are available on all major platforms
(or whatever). 

Personally, I suffer most from the fact, that Pd-extended is a
separately maintained Pd with patches on one hand and a collection of
externals on the other. If it would be simply a Pd with a collection of
externals, it would be much simpler to just update Pd and add - for all
I care - a frozen collection of externals. Pd-extended was always  one
or two versions behind Pd. Now it's already three. If I want to make my
stuff portable and available to non-Pd-savvy people, I have to stick
with compatibility with Pd-extended 0.43, which is a huge pain,
considering what more recent versions of Pd offer ([array], [text],
[oscparse], new methods for time based objects, etc.). 

I agree with you that there is a lot of mess and redundancy. But I'm not
sure if it matters that much. 

Roman