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

[Roman Haefeli]

On Tue, 2010-07-13 at 13:18 +0200, Frank Barknecht wrote:
> Hi,
> 
> On Tue, Jul 13, 2010 at 12:43:08PM +0200, Roman Haefeli wrote:
> > Last time I checked, [declare] indeed was working inside abstractions.
> 
> Depends on what you call "working" ...
> 
> Quoting the help file: 
> 
>     WARNING: you might want to avoid putting "declare"
>     statements inside abstractions, as their effects will
>     extend to the calling patch. As of version 0.41, "declare
>     path" is ignored inside abstractions, although, probably
>     unwisely, "-stdpath" takes effect (on the calling patch as
>     well as the abstraction.)
> 
> Attached is an example showing where declare in abstractions fails: 
> Open abstraction-help.pd, then click "abs/abstraction" to see an object
> not created, although it's in the [declare]ed path. Open
> abs/abstraction.pd directly then: now the object creates.

This is a nice example, which exposes clearly the culprits with
[declare]'s current implemtentation. Thanks for sharing.

[declare] is definitely not ready for 'intra-project' usage. However, it
still can be used as a replacement for the command line flags '-lib' and
'-path' for system-wide installed libraries and that was the use case I
initially was talking about. Instead of Pd-extended loading system-wide
installed libraries per default, those also could be loaded with
[declare -stdlib], respectively [declare -stdpath]. And those work also
inside abstractions. 

As you pointed out, [declare] still has issues. However, in the long run
it'd be the preferred way to load dependencies dynamically from the
patch instead of generally and automatically on start-up. Do we agree
here?

> Also see the source for abstraction-help.pd to spot the "#X
> declare"-pollution.

It was me who reported this bug back then. And it is still not fixed. 
http://sourceforge.net/tracker/?func=detail&aid=2251387&group_id=55736&atid=478070