On Fri, 3 Apr 2009, Enrique Erne wrote:
My workaround is an abstraction with the name dyn~, this sends a message "dyn~ not available" if it gets loaded. Then I found out that pd-0.42 can do object aliasing (not sure if that is the correct term)
I didn't see any reply at all to this, so, I'm gonna have a try at it, even though it was 4 months ago.
if I try to guess what you mean, you mean how a class being loaded can override a previously-loaded class. well, this only happens if a class is being loaded, and pd doesn't look for it if it already knows the name. so, normally, it depends on a -lib option or anything else that acts like a -lib option.
Now, there is something else called aliasing, which can occur in combination with the above or not, and exists since the beginning of Pd. When people don't claim something like "[t] is an object", they'd claim the more correct "[t] is a class", which is how I'd say it, even though it's not exact. The exact thing is that [t] is a name of a class, and it's not the main name, as [trigger] is the main name, but from a user's perspective, both names are equal. they correspond to the exact same class.
There's also an opposite to that, which is that a single name can correspond to several classes. This is the case of [sel], for example.
The only way I can think of having your [dyn~] thing work is by making the relevant -path directive the last folder in the search-path and making sure it stays that way. But I wouldn't like to do that. GridFlow 0.9.5 now adds a method called "else" in Pd's builtins (yes, an external can do that!) which is used for exactly what you want, but only during dynamic patching. Well, no, actually it could also work in hand-modified .pd files) :
#X obj 666 42 dyn~ blah blah; #X else obj 666 42 dyn~-was-not-found blah blah;
and you define [dyn~-was-not-found] as something that apologises for the hopefully temporary inconvenience.
What "else" does is create an object ONLY IF the last created object became a dashed object, and in doing so, it deletes the dashed object so that it can pretend that the replacement is really what was intended. (saving this patch will save whichever actually loaded object as a normal object and the "else" will disappear).
which i find a very confusing feature. I was worried that my workaround wouldn't work anymore if the abstraction would "overwrite" the external, but it seems all fine. So the question is are there plans to make abstractions alias object classes ? (i hope not :) )
an abstraction is an object class.
but abstractions can't do the new 0.42 trick because they can't do any class_new or class_addcreator themselves, so they can't register any name on their own, so each file can only contain one abstraction whose name is the same as the file.
with the 0.42 trick, the name is overridden and not overwritten, but you can't tell the difference. with the same thing before 0.42, the new name seems to be disappearing, but it's really there and overridden by the old one. You can also use "evil" trickery to add, replace, reorder or remove any name, with any version of Pd so far, but then, it's risky.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec