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 _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev