[PD] declare [was: Re: Idiomatic Pd]

[Hans-Christoph Steiner]

On Jul 30, 2008, at 4:01 AM, Frank Barknecht wrote:

> Hallo,
> Matt Barber hat gesagt: // Matt Barber wrote:
>
>>>
>>>> When 0.39 begins to wane (so [declare] can be used),  ...
>>>
>>> Careful here: [declare -path ...] is disabled inside of abstractions
>>> in Pd-0.41.
>>
>> Right -- but [declare -path ...] is terribly useful for not having a
>> patch's main directory cluttered with 100 abstractions, which was the
>> main point... but since 0.39 is still widely in use I tend to  
>> avoid it
>> unless it's for patches I know only I am going to be running.  I  
>> guess
>> it's okay to be conservative in some parts of life.  =o)
>>
>> OT -- out of curiosity, if it were to be enabled within an
>> abstraction, would the -path be relative to the abstraction file  
>> or to
>> the patch in which it's instantiated?
>
> Relative paths are important if you use declare in the way you
> described here: to make shipping "bundles" easier by putting all used
> abstractions into a subdirectory and adding that subdir to the
> searchpath of the MAIN.pd. As you don't know where a user puts your
> project, you cannot use absolute paths.
>
> Now inside of an abstraction I would discern two use cases: One is
> using declare just as in the MAIN patch to add further subdirectories
> for other helper abstractions. Here the only thing that makes sense
> IMO when using relative paths is to have them relative to the
> abstraction itself.
>
> Another use case is the path for "resources" like soundfiles or
> sequencer patterns. The example Miller once mentioned on pd-dev was
> having a [soundfiler] in a sample player abstraction. Usually this
> abstraction would live somewhere far away from your soundfiles or your
> MAIN.pd.
>
> [soundfiler] also looks for soundfiles in the pd search path, so users
> may feel inclined to manipulate the path to make the sampler
> abstraction find wav-files in a "snd"-directory somewhere without
> giving the full absolute path. Here it probably is more common to use
> paths relative to MAIN.pd instead of sampleplayer.pd so the
> MAIN-file's -path setting would reach into the child patch as well.
>
> A drum synth abstraction may be different again: Maybe it has some
> default samples for kick and hihat in a subdirectory next to itself.
> Now you could manipulate the path to make it find these samples first.
> Again absolute paths don't work here, as your synth.pd may be
> installed anywhere.
>
> As there is no consensus which of the two path alternatives should be
> used inside an abstraction, -path currently is disabled completely in
> an abstraction. (Btw. I don't know how an abstraction knows that it's
> used as an abstraction, not as MAIN.pd.)

There is consensus if we consider how other programming languages  
have done it.  From what I have seen in Python, Java, and C (and  
probably many others) there are two options:  global and local-to-the- 
file.

If we want to have namespaces working, then I suggest we use the  
tried-n-true model of other languages.  If people are really  
interested in experimenting with ideas of how to handle namespaces,  
then we could try other options.  Either way, we should start by  
getting the tried-n-true model working first, IMHO.  Then if people  
want to experiment with things like inheriting namespaces from the  
parent, there will be a solid, working foundation to build upon.

I plan on working on this in depth before the end of the year.

.hc

>
> Ciao
> -- 
>  Frank Barknecht                                     _  
> ______footils.org__
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list


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

Access to computers should be unlimited and total.  - the hacker ethic