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