[PD] declare [was: Re: Idiomatic Pd]
reduzierer at yahoo.de
Thu Jul 31 10:17:17 CEST 2008
On Wed, 2008-07-30 at 21:09 -0400, marius schebella wrote:
> 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.
i still think this approach is much more troublesome. why should a
[declare -path] inside an abstraction expand the home of the topmost
parent patch while keeping the scope within the abstraction itself? this
is two levels of nesting too much and completely not necessary. this is
hard to follow and wouldn't pd life make easier at all. if you want a
path relative to the topmost parent patch, then this path should also be
declared in the topmost parent patch. if you want to use global pathes
for the whole project, then those pathes should only be declared in the
> > 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?
for the 'relative to parent' approach you would need to set the
abstractions home to the topmost parent's one, so that it expands pathes
correctly. 'relative to file location' is not only very easy to
understand, it also doesn't change how pathes are handled now.
> > 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....
put the declare in the topmost patch. either you have the sample folder
in a project specific place, then it also needs to be declared in the
project's main patch, or it is always at the same place relative to
'mysfplayer', then it could be declared inside 'mysfplayer'.
ok, i see, that by proposing this i make some assumptions, that probably
aren't obvious (i make those, because it seems to me the only obvious
way to do it):
- pathes are inherited from the (any) parent
- inherited pathes are already expanded pathes, which means:
'-path ../yoyo' from the parent doesn't expand the abstractions
home with '../yoyo', but instead the abstraction uses
'/path/to/parent/../yoyo', which is inherited form the parent.
yo.. let us try to find use cases, that _cannot_ be covered by this
approach. if we don't find them, then let us please find the consensus
(aka. going for the 'relative to file location' route).
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
More information about the Pd-list