[PD] pd extended development
hans at eds.org
Wed Apr 16 23:55:43 CEST 2008
On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote:
> marius schebella hat gesagt: // marius schebella wrote:
>> Frank Barknecht wrote:
>>> 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
>>> is, when two objects have the same name registered in Pd but act
>>> differently. Folders are a way to organize files in a filesystem
>>>> 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,
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