On Wed, 2010-07-14 at 08:31 +0200, Frank Barknecht wrote: > Hi, > > On Tue, Jul 13, 2010 at 11:07:08AM -0400, Mathieu Bouchard wrote: > > On Tue, 13 Jul 2010, Frank Barknecht wrote: > > > > >I would love a proper way for Pd vanilla/core to load libraries > > >into abstractions. I know of [import] but most of my abstraction > > >libraries target vanilla installs, too, so I cannot use it. And > > >[declare] currently is designed for top-level _main.pd-style > > >patches only, so there's no way to really preload list-abs in > > >RTC-lib-abstractions for example. > > > > It's not even working for top-level patches, because what you load > > for one top-level patch is also loaded for all subsequent patches > > until you restart pd. > > If I interpret Miller's intentions for [declare] correctly, that's what > it's designed to do. (I base my interpretation partly on his use of > [declare] in the Pure Data Repertory Project PDRP.) > > In my interpretation, [declare] is intended to be used in a single > MAIN.pd and is the place to load all dependencies for all abstractions > used inside that project ("dependencies" includes things like paths to > resources like samples etc.). So if an abstraction you use complains > about missing a [list-drip], add a [declare -(std)path list-abs] in MAIN.pd.
Your interpretation does not quite reflect, how [declare] currently behaves: * [declare]ing a path in top level patchA.pd does not affect top level patchB.pd. In that respect, [declare] _is_ canvas local. * [declare]ing a path in abstraction [abs] which is instantiated in patchA.pd does not affect patchA.pd. Also in this respect it is canvas local. * A [declare] with a flag, that is supposed to be relative to the patch ('-lib' and '-path') expands always only relative to the path of the most top level patch (see your example). This actually renders those flags unusable within abstractions. * [declare -stdlib] and [declare -stdpath] still can be used within abstractions, since those flags are relative to the Pd path and thus independent from the most top level patch. * [declare -lib] and [declare -stdlib] cannot load a class library or single classes canvas local. But this is probably more related to the classloader of Pd than specific to [declare] (and is the same with [import]). * [declare] still has bugs. When saving a patch after having instantiated an abstraction containing a [declare], the patch is polluted with a hidden [declare]. This does not mean, that [declare] is not canvas local. > When used in this way as we do in all the RjDj scene archives[*] > [declare] works very well. But [declare] does not help with > canvas-local loading at all, probably because it's designed with > different intentions. To declare is not to import. This is also not true. The combo libdir and [import] behaves very similar to [declare -stdpath] in that it is canvas local in the same respects as described above and also in that it expands pathes relative to Pd. A difference is, that it requires a mylib-meta.pd patch. If you want, [declare] is an extended [import] with bugs under certain circumstances. > (It took me a while to realise all that ...) After all, I don't see why one should restrict themselves in [declare] usages as you propose it, OTOH it's certainly safe. Roman _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list