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

marius schebella marius.schebella at gmail.com
Thu Jul 31 03:09:00 CEST 2008

Roman Haefeli wrote:
> On Wed, 2008-07-30 at 10:01 +0200, 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.) 
> i question, if someone is seriously voting for the 'relative to parent'
> approach, since it is full of troubles:

I think, I do. (if seriously is another question...)
to me an abstraction is like an include function (like for example in php).
let's say I create an abstraction that plays soundfiles and the filename 
can be given as an argument or messages, then I want to write
[mysfplayer sounds/1.wav]. in this case, I want the file be relative to 
the "parent" patch, because the parent patch will be in my project 
folder, but the abstraction will be somewhere in an abstraction directory.

otoh, if there are files that mysfplayer is depending on, for example a 
bg image with playbuttons.. which are relative to the [mysfplayer] 
abstraction, then they would still be found under images/button.gif, 
because if the abstraction[mysfplayer] is in the search path, then the 
images folder should be in the path, too.

making all paths relative to abstraction is reduntant imho.

> 1. it's not clear, what the parent is: is it the top-most patch or the
> patch, that is the direct holder of the abstraction (or any other level
> in between)?

the topmost.

> 2. from what i know, in pd the 'home' of any instance of any patch or
> abstraction has been and still is the _file location_ of the patch or
> abstraction, no matter where you instantiate them from (menu->open or
> [path/to/file]). the 'relative to parent' approach would break this.

I don't think it would break it, how?

> 3. if i am not totally mistaken, pd doesn't distinguish between
> abstraction and patch, but they are both very much treated the same. i
> think, this is a strength of pd, because it makes patching very
> scalable: what once was a patch, can be used as an abstraction without
> any changes. pd 0.40 breaks this by ignoring [declare -path] inside
> abstractions, which is a bad and hopefully temporary solution, imo. the
> 'relative to parent' approach would definitely introduce the distinction
> between abstractions and patches for almost no gain, imo. 
> if possible in whatever way, i really would like to push the consensus
> towards the 'relative to file location' approach, in the name of the
> church of consistency and also just for the finding a consensus' sake.

At least for the example above (mysfplayer) I don't see how this should 
work with the "relative to file location" approach....


More information about the Pd-list mailing list