[PD] declare who? what?

Roman Haefeli reduzierer at yahoo.de
Tue Jun 3 14:54:29 CEST 2008

On Mon, 2008-06-02 at 13:21 -0400, Enrique Erne wrote:

> also i am a bit disappointed that one can not write abstractions, that 
> declares what it depends on. but probably that has some technical reason.

this issue hasn't been solved yet, AFAIK. actually i am not even sure,
what the problem might be. probably it is not clear how to expand search
pathes for an abstractions without expanding the pathes of the parent
patch. however (sorry to repeat myself), i think it is quite
problematic, that since the introduction of [declare] there is an
implicit difference between abstractions and patches, whereas before
they were treated exactly the same, in the sense, that it didn't make
any difference whether you opened a *.pd-file as patch or instantiated
it as an abstraction.

is there already an agreement on how it should be implemented ideally?
i am still confused, even if i tried to follow all the threads regarding
that topic. 

when writing a patch, i don't want to think about the dependencies of
the abstractions i use. that is why i propose the following layout: 

in my idea of an ideal [declare -std*] layout, it expands search pathes
only locally to the patch and all its children (abstractions and
abstractions of abstractions). the same goes for abstractions: search
pathes are added for the instance itself and all children, but not for
the parent patch nor other instances at the same level. search pathes
added by the local [declare] should be checked _before_ the parent
[declare] before the grandparent [declare] etc. 'relative' means always
relative to the location of the file and not relative to file location
of the most top parent patch (or anything else).

i think, this would be a clean and easy to understand layout, since it
is quite similar to how [block~]/[switch~] are working.

does that make sense? am i overseeing problems, that aren't covered by
this layout? frank, you probably made the most complex abstractions
regarding nesting of depencencies (i am thinking of [nqpoly4]). would
this layout work for projects using [nqoly4]?

in the name of the church of consistency, i truly hope, that we can come
up with a layout, that everyone (miller included) agrees on. sorry, if
that _did_ already happen and i missed it.


Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

More information about the Pd-list mailing list