[PD] [declare]: -path seems not to be added to the searchpathes

Frank Barknecht fbar at footils.org
Mon May 28 22:42:35 CEST 2007


first: Maybe we should avoid the term "parent patch" for the patch,
that contains the [declare] object. Generally "parent" seems to be
used for specifying the parent of an abstraction as in "graph on
parent".  One could consider an object like [declare] to be like an
abstraction and then its parent would be the patch that contains
[declare]. However IMO this becomes confusing when talking about the
parent of an abstraction that itself contains the [declare]. 

Does someone have a better term for the patch, that contains an
object? Maybe the "owner" or so.

Roman Haefeli hat gesagt: // Roman Haefeli wrote:

> what i meant to be inconsistent:
> - [declare -lib somelib] makes the objects of the external 'somelib'
> availabe to ALL patches, not only to the [declare]'s parent patch.

Currently it's impossible to "unload" a binary object (builtin or
external) from Pd once it is loaded. Loading the wrong [counter]
binary will make all your [counter] objects behave like the one loaded
first. That's also why you cannot overwrite binary objects with
abstractions. Just try it.

So the fact that [declare -lib somelib] acts globally actually is
unavoidable and might even be considered a bug.

> - [declare -path somefolder] makes the abstractions from 'somefolder'
> available ONLY to the parent patch, i.e. the patch, that contains the
> [declare].

That's the idea IIRC: Only the "owner" should see that modified path.
Unfortunatly that behaviuor is currently broken for [declare -path
...] in abstractions.

 Frank Barknecht                 _ ______footils.org_ __goto10.org__

More information about the Pd-list mailing list