[PD] pd extended development

marius schebella marius.schebella at gmail.com
Wed Apr 16 21:48:11 CEST 2008

Frank Barknecht wrote:
>>>> the thing that I was complaining so loudly is that pd-extended ships all 
>>>> these libraries but does not add the paths. 
>>> Yes, that's exactly what I mean: Many people would like every
>>> objectclass to be global. 
>> but that is not a problem for pd-extended users (and I want to solve the 
>> pd-extended problems here), as long as you can overrule the global 
>> namespace with a local namespace.
> Not really: Say I use [urn] in Pd-extended. Which [urn] am I using? 

all people interested in pd-extended would have influence on the order, 
like hans, you, me... we would provide a list with all nameclashes 
inherent in pd-extended and how to access the non default classes. (at 
least that is my intention.)

> As pd-extended by popular demand (and for practical reasons) is
> configured to allow access to one of the [urn]s out of the box, I
> believe not many people are actually using the names [zexy/urn] or
> [maxlib/urn] or [cyclone/urn].  But all of these behave differently.
> So we have a hidden nameclash if you try to use a patch that assumes
> [urn] to be the one from the library, pd-extended loads as the second
> one. 

additionaly we could have a printout everytime you try to load a class 
that is in a nameclash with another one the sonsole, but that would be 
annoying too, no?

> Now IIRC Hans' goal is to not load any library or set any path
> out of the box, so that all names would have to be qualified with
> directory prefixes or [declare]d. 

yes, but I think it *should* be set out of the box.

>> pd-extended would provide a default object for every nameclash.
>> If you have old patches that were using objects, that are not the 
>> default in pd-extended you would have to add a declare to your patch. or 
>> explicitely call them as mynondefaultlib/abs~.
> So you see: pd-extended selected a certain set of externals to be the
> default set of available objectclasses in pd-extended. I don't know
> how it was decided which libs should be these defaults, I don't even
> know which ones are the defaults. Probably Hans just chose some
> popular ones, which is a sensible thing to do. 

noone knows which objectclasses are loaded by default, and nobody ever 
decided this, everything is arbitrary, but I have not given up the hope 
that this will change soon.
if you have this published list of objects that pd-extended uses and 
want to write your own abstractions, then you would have a good 
reference of taken names, and this will prevent further nameclashes in 
the future. more people would focus on *one* list of available pd 
objects and name their abstractions in reference to the already existing 

> In the long run, this process should become a bit more organized 

my words...

> it especially should not be handled along library/author borders.  For
> example, I think, zexy (rightfully) has a high loading priority,
> because it's one of the oldest and most widely used library. But
> Cyclone also deserves a high priority because it's generally
> Max-compatible. OTOH zexy is older. What to do? If we only priorize
> complete libraries, we're not able to make finely grained decisions
> about single objects. Maybe zexy's [abs~] is better, while [urn] in
> Cyclone is preferable.

how many nameclashes do we have? 20, 30? how many libraries are affected 
5? yea, that's what has to be done.
the situation right now is worse than any solution with a default class. 
because an object like urn is already problematic. a mentored 
"quasi-official" pd-objectclass list would at least guarantee future 
compatibility for the one class that would be considered the default. 
and the other urns would have to be explicitely called with notdefault/urn.
but that is exactly what needs to be done to prevent nameclashes. if you 
don't do it, then you never will have compatibility...


More information about the Pd-list mailing list