[PD] benevolent dictator? (was: 2d multiple preset interpolation?)

[Roman Haefeli]

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