[PD-dev] "declare" strangeness in abstractions (0.41 test10)

[Frank Barknecht]

Hallo,
Miller Puckette hat gesagt: // Miller Puckette wrote:

> Well, I can't remember now if I was looking at that bug report or if I was
> having my own problems with declare (I've had many).  I had bad confusion
> making abstractions use "soundfiler", for instance, and having relative
> paths get expanded relative to the abstraction instead of the calling patch.

This sounds similar to the problem my [polypoly] abstraction
generates. [polypoly] is called with the name of an abstraction and
dynamically creates several instances of that abstraction to simplify
building polyphonic patches. Assuming polypoly.pd is in /poly/path
which is part of the search path, then if a patch X.pd somewhere else
is using [polypoly instrument] with instrument.pd next to X.pd,
[polypoly] will not find instrument.pd, because polypoly.pd is in
/poly/path and doesn't know about any instrument.pd. The fix is to
either add the path to instrument.pd or copy polypoly.pd over to the
directory of X.pd and instrument.pd. 

The path to instrument.pd however cannot be added with [declare], as
[declare] is and should be local to a canvas, which in this case is
the parent's canvas, not the canvas of polypoly.pd.

> However, when an abstraction opens a sub-abstraction as in "x/y", I think
> it's best to have x/y be relative to the abstraction's location and not the
> calling patch's.  

Yes, I agree.

> These two needs seem in direct conflict.  I hope to figure 
> out a better way to handle this but have given up trying to resolve it 
> for 0.41.  
> 
> I hope nobody is yet throwing "declare" objects in abstractions, as that
> currently does something so wrong (altering the global path for the calling
> patch!?) that I thought it better to get rid of the whole thing for now.

[declare] in abstractions was broken or inconsistent anyways (that's
what my bug report was about) so I don't think anybody is depending on
[declare] to work in a specific way for abstractions currently.

OTOH as every patch file could be used as an abstraction as well,
making the use of a patch file as an abstraction a special case could
be a recipe for trouble. ;)

So in the long run (e.g. for 0.42) some kind of specification how
[declare -path X] should work in abstractions would be necessary. 

I always thought of [declare] as an object that modifies settings for
the local canvas only. I think, Hans' [import] does that and I believe
it's sensible. But I may be missing possible side effects. 

Anyway I would expect [declare -path DIR] to add "DIR" to the local
canvas' searchpath with "DIR" relative to the current patch's path.
Basically it would make an object in [DIR/file] be available as [file]
as well. For absolute paths like [declare -path /DIR] it would add the
absolute path. A declare in a parent patch then should not modify the
path of an abstraction used. 

However, as the polypoly-example and maybe some soundfiler use cases
show, sometimes it can be useful or even necessary to access a
parent's path settings. I don't know how to allow that in a useful
way. Maybe with some additional option to declare like [declare
-addparentpath]? Tricky ...

Ciao
-- 
 Frank Barknecht                                     _ ______footils.org__