[PD] Extending Vanilla (was Cyclone help patches & issue list)

Dan Wilcox danomatika at gmail.com
Thu Dec 18 04:03:13 CET 2014

I agree. It became too much for one person and this could be a more reasonable way to move forward.

I say “divide and conquer”. We all recognize and applaud the work that Hans has done, but at this point, I feel the centralized external repository is the main stopping point every time someone has to ask who is maintaining what and if they can have svn access to provide a patch.

I think most externals have managed to weed themselves out over time. You basically listed the most stable externals (iem ones). I’d add mrpeach and cyclone to that list. A lot of the others have gotten pretty hairy and probably don’t need to be kept active at this point.

We could start by moving popular externals off of the sourceforge svn and into separate Github repos, each with a maintainer. Getting them onto Github alone would be worth it in that it’s plainly a lot easier to collaborate. People would be then free to support the externals they want and the strongest ones would continue on. This could be done through a Pure Data group, like the “pd-projects” group. Old, unused externals could be kept in the svn until someone wants to “promote” them and volunteers to maintain them.

This model has worked very well for OpenFrameworks. In OF, we've standardized around an “addon” external source code/library format and naming convention and there are now quite alot of useful addons in the wild. There’s even a website which indexes them based on metadata off of Github: http://ofxaddons.com <http://ofxaddons.com/>. Hans has already put together an external template and makefiles and I’m sure we could build similar indexing site for pd-externals (or I can ask for the ofxaddons.com source code).

It would be great to have each external or related groups like iemlib working as a separate download/clone that just builds out of the box. That would be the first step toward integration with build servers to provide binaries. Unlike OF which is distributed as source code, we *have* to provide binaries which is one of the hardest parts of maintaining software. It’s alot easier if the work is split up so the Linux people can package the external (lie IOhannes and Debian), then OSX people can build new versions, and the Windows people can build new versions now and then. A cherry on top would be making sure the makefiles work *really* well and there is good documentation on how to use them so beginners are more likely to pitch in and try. This model has worked well for OF and Max externals have been distributed as source code/binaries for years now.

I think this makes sense, really. It removes the burden of having to maintain a mega release like Pd-extended and splits up the external maintenance. It does, however, require end users to manually download the externals they need, but that’s not a huge deal if we make it as easy as possible.

Dan Wilcox
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Dec 17, 2014, at 9:33 PM, Alexandre Torres Porres <porres at gmail.com> wrote:
> Hello, I don't know if Hans is replaceable and I didn't mean to start a thread about "replacing" him or even point to a new "extended"distro.
> I just wanted to highlight what miller mentioned about people considering working on a repository of external objects compatible to vanilla, and how all extended libs should work on vanilla and that he was willing to help make'm work in it.
> I, for one, think that's good enough to work as an "extended" replacement, while hans (or any other who'd replace him) carries on with pd-extended (or some new distro).
> As far as library management and maintenance goes. In my opinion, maybe that shouldn't be a burden that someone has to carry alone. I don't believe Hans vouched for being the one responsible for maintaining that much libraries on his own. I believe he ended up doing so because the original developers just didn't care anymore and abandoned it...
> I have to say that's a hell of a bummer. And that I've had some experiences trying to reach creators and maintainers about a bug on some extended object and got not much help of something like "yeah, I know about it but I don't have time to work on it".
> I love the work Hans did with Pd extended, and still use it, but I'm critic on how many libraries and objects are badly maintained, with bugs and not that good documentation. There are also many redundanct objects. So can't say it's such a great package of externals... 
> I know there are a few libraries I can't live without. Like, from the top of my head there are: zexy, iemlib, cyclone... I'd be kinda done with these few libraries.
> In the scenario context we're discussing - of a repository of working libraries - if whoever made a library that was on the repository and, for some reason, it stopped working, I guess the creator should care to maintain it. but if he doesn't, if it's open source and everything, maybe someone else who cares would care to step in and deal with it.
> But I have the idea that if a library is working fine as an external in vanilla, it should normally keep working as such. And Miller is here waving . And well, if it doesn't and nobody cares. Then it is crossed out of the repository. Simple as that...
> So, it's a whole different paradigm. It's not about building and releasing a new distro. It's not about telling Miller what he should do with Vanilla. And it should be pretty simple as I see it. Moreover, I could manifest the opinion that that's the easy way and how it should be - a list of plugins, nicely organised somewhere, for people to download and use it. 
> And no need for that much diplomacy. I think it should be open and free. If people make some libraries and wanna to put it on the repository, just let'em do it.
> Well, that's my two cents
> Cheers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141217/8b9b4a8a/attachment.html>

More information about the Pd-list mailing list