[PD] canvas path

[Jonathan Wilkes]

My point is that if you leave these things as an exercise to the user, then the user loses.  The rules for how things load are too confusing, and Pd traditionally has too few tools for the user to inspect path order, aside from trying every single possibility.

A user shipping an abstraction library with abstraction helpers that load with impunity... is not actually possible.  That means the author of a library of abstractions is subject to whatever search path the parent canvases have set for it, which will _supercede_ the abstraction's directory. "Use your own name-mangling" isn't a serious solution.

-Jonathan



On Tuesday, October 21, 2014 4:40 AM, Frank Barknecht <fbar at footils.org> wrote:
 


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__


_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141021/885b965e/attachment.html>