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

Roman Haefeli reduzierer at yahoo.de
Thu Jul 31 01:50:00 CEST 2008

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:

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)?

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.

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.

(sorry, if i am pushing to hard..  too much beer)


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

More information about the Pd-list mailing list