On Tue, Feb 15, 2011 at 03:09:35PM -0800, Jonathan Wilkes wrote:
--- On Tue, 2/15/11, Mathieu Bouchard matju@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__