[PD] pd extended development

Hans-Christoph Steiner hans at eds.org
Wed Apr 16 23:55:43 CEST 2008

On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote:
> 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? ;)

The flatspace model breaks down when you start adding libraries to Pd- 
extended.  Then you can have nameclashes again.  Say someone writes  
their own library with an [urn], then what happens?  At best,  
confusion ensues.

If we look at other programming languages, we can see that namespaces  
are a very common  solution to this problem (C++, Tcl, python, Java,  
Smalltalk, etc).  I see no reason why it wouldn't work for Pd as well.



There is no way to peace, peace is the way.       -A.J. Muste

More information about the Pd-list mailing list