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,