Hallo,
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.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__