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

[Hans-Christoph Steiner]

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




------------------------------------------------------------------------ 
----

                             kill your television