Hi,
maybe I didn't make clear enough, that of course some of these fail to load the abstractions they may try to load: That's intentional and the whole point of this routine.
The interesting point that in my experience many Pd users are not aware of, is just this: The directory of a calling patch (0*.pd in this case) is not part of the search path for abstractions used by this patch!
This not only applies to abstractions, but also to other material like soundfiles, textfile, textures etc. because there is only one search path.
If you compare 01_loadhere.pd and 03_loadhere-declare-dot.pd you see:
[declare -path .] is a way out here. As Jonathan has analysed most cleverly and as I have shown in a more frugal way: With the directory of the toplevel patch added to its search path it becomes possible to load here.pd from an abstraction as intended.
A side effect is a possible nameclash, illustrated in both.pd. This makes it tricky to use other objects in the library. Using a prefix or more path-mangling is necessary. Updated examples in the attachement should illustrate this as well.
It is left as an exercise for the reader to implement a mylib/meta-metaload.pd that loads "metaload both" while being called from a toplevel patch like [meta-metaload both].
Have fun,
Frank Barknecht _ ______footils.org__