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__