[PD] FLOSS book Lists chapter

[Frank Barknecht]

On Tue, Feb 15, 2011 at 03:09:35PM -0800, Jonathan Wilkes wrote:
> --- On Tue, 2/15/11, Mathieu Bouchard <matju at artengine.ca> wrote:
> > The idea of Vanilla-without-externals is probably most
> > useful to ZenGarden users, who can't compile any existing
> > externals, because ZenGarden was designed to be incompatible
> > with Pd-Vanilla. It is because of this incompatibility, that
> > Zengarden users are led to excessively focus on what's
> > compatible with Vanilla-without-Externals, because that's
> > all that the ZenGarden project aims to support.
> > 
> > Just another hypothesis. What do you think ?
>
> I think it's useful to people doing stuff with audio who want to learn Pd
> without being surrounded by a haze of thousands of possibly useful, possibly
> buggy, poorly documented object classes that may or may not be usable for
> someone on a different machine.  The danger, however, is that one can end up
> arbitrarily limiting the types of projects one does to a narrow subset that
> fit the types of tools available with "Pd-minus-externals"*.  Then again
> maybe the limited set of tools is what attracts that user in the first
> place...

I think, Matju may be overestimating the number of Zengarden users a bit, but
as ZG was started by an RjDj developer, maybe he meant to refer to RjDj in
general. 

With RjDj the main motivation for restricting the number of included
object classes to those in Pd vanilla (plus a few) was to provide a standard
working platform for musicians and listeners that is long-term maintainable on
limited hardware and limiting operating systems. 

Pd-extended was ruled out, because it does (or did) not provide a suitable
level of standardization: The libraries in Pd-extended have a lot of
overlapping functionality, because they were just "thrown together" from what's
in the SVN repository. Many make no sense in the RjDj context anyway and all in
all having to package and distribute and keeping up to date such a large
package is a maintaince nightmare. (It's also a legal nightmare in Apple's
AppStore, but that's a different story.)

So RjDj deliberatly restricted itself to vanilla (and not deliberatly had to
throw out [expr] because the lawyers said so).  The rj abstraction library
makes using vanilla a bit easier, but it's not directly part of RjDj, it's just
something you put into your patch directory. 

Pd vanilla has a stable set of objectclasses of generally good quality, they
are tried and true and we have found them to be close to industry strength.

But most importantly Pd vanilla in reality is the only thing that can be called
a "standard" set of object classes - it's the only real "standard library" the
Pd community has been able (or been forced) to agree on in the many years I'm
using Pd. This may be of no importance to people writing Pd patches for their
own single laptop, where they can re-install missing objects quickly. 

But it's absolutely crucial if your goal is to distribute the patches to
hundreds of thousands of iPod/iPhone/... users, as RjDj does for about to years
now.

Ciao
-- 
 Frank Barknecht            Do You RjDj.me?          _ ______footils.org__