[PD] pd extended development

Frank Barknecht fbar at footils.org
Wed Apr 16 20:58:49 CEST 2008


Hallo,
marius schebella hat gesagt: // marius schebella wrote:

> Frank Barknecht wrote:
> > Hallo,
> > marius schebella hat gesagt: // marius schebella wrote:
> > 
> >> sorry, I still don't know exactly what you mean. I think it is the only 
> >> solution to keep libraries in subfolders if we want to solve 
> >> nameclashes. but even if in subfolders, they should be accessible as 
> >> list-abs and not list-abs/list-abs.
> > 
> > Huh? Nameclashes have nothing to do with subfolders per se. A nameclash
> > is, when two objects have the same name registered in Pd but act
> > differently. Folders are a way to organize files in a filesystem
> > (harddisk). 
> > 
> >> 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? 

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. 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. But when this behavious accidentally
came into effect because of the change in plist-location on OS-X,
people complained about missing objects and that their patches were
broken with the new pd-extended.  Note that I don't want to rate if
they complained for a good reason, I just want to point to a problem.

> 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. 

In the long run, this process should become a bit more organized and
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.

In the end we may be back at square one: a "flatspace" with the
selected best of the (un)pack objectclasses in a single directory. No
problems with path settings, all is fine again. 

Or what am I missing? ;)

Ciao
-- 
 Frank Barknecht                                     _ ______footils.org__




More information about the Pd-list mailing list