On Jan 5, 2008, at 10:13 PM, Frank Barknecht wrote:
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.
As it stands, [import] is a sketch of how I think the interface should work, and it currently uses the same code as [declare] to do its work. I am planning on working on this stuff more in the near future, hopefully we can come up with a simple, clean solution for all this. It would save us a lot of trouble, IMHO.
.hc
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__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
kill your television