|Luke Iannini||Jul 27, 2008 6:33 pm|
|Luigi Rensinghoff||Jul 28, 2008 4:01 am|
|Hans-Christoph Steiner||Jul 28, 2008 1:39 pm|
|Chris McCormick||Jul 28, 2008 7:48 pm|
|Luke Iannini||Jul 28, 2008 9:48 pm|
|Frank Barknecht||Jul 28, 2008 10:31 pm|
|Luke Iannini||Jul 28, 2008 11:07 pm|
|Luke Iannini||Jul 28, 2008 11:29 pm|
|Frank Barknecht||Jul 28, 2008 11:53 pm|
|IOhannes m zmoelnig||Jul 29, 2008 12:13 am|
|Matt Barber||Jul 29, 2008 12:18 am|
|Frank Barknecht||Jul 29, 2008 1:04 am|
|Enrique Erne||Jul 29, 2008 5:01 am|
|marius schebella||Jul 29, 2008 7:01 am|
|Matt Barber||Jul 29, 2008 7:28 am|
|Frank Barknecht||Jul 29, 2008 8:39 am|
|Matt Barber||Jul 29, 2008 9:41 am|
|Hans-Christoph Steiner||Jul 29, 2008 10:29 am|
|Hans-Christoph Steiner||Jul 29, 2008 10:33 am|
|Hans-Christoph Steiner||Jul 29, 2008 10:34 am|
|Frank Barknecht||Jul 29, 2008 11:04 am|
|marius schebella||Jul 29, 2008 11:23 am|
|marius schebella||Jul 29, 2008 11:25 am|
|Hans-Christoph Steiner||Jul 29, 2008 12:09 pm|
|Hans-Christoph Steiner||Jul 29, 2008 12:10 pm|
|Mike McGonagle||Jul 29, 2008 12:40 pm|
|Matt Barber||Jul 29, 2008 12:43 pm|
|Thomas Mayer||Jul 29, 2008 12:53 pm|
|Matt Barber||Jul 29, 2008 1:28 pm|
|Hans-Christoph Steiner||Jul 29, 2008 4:47 pm|
|Frank Barknecht||Jul 30, 2008 12:16 am|
|Frank Barknecht||Jul 30, 2008 1:01 am|
|Chris McCormick||Jul 30, 2008 1:46 am|
|Hans-Christoph Steiner||Jul 30, 2008 9:12 am|
|Frank Barknecht||Jul 30, 2008 10:10 am|
|marius schebella||Jul 30, 2008 12:14 pm|
|Frank Barknecht||Jul 30, 2008 12:34 pm|
|Roman Haefeli||Jul 30, 2008 4:49 pm|
|marius schebella||Jul 30, 2008 6:08 pm|
|Hans-Christoph Steiner||Jul 30, 2008 8:31 pm|
|Hans-Christoph Steiner||Jul 30, 2008 8:44 pm|
|Frank Barknecht||Jul 30, 2008 11:20 pm|
|IOhannes m zmoelnig||Jul 31, 2008 12:33 am|
|Damian Stewart||Jul 31, 2008 1:11 am|
|Roman Haefeli||Jul 31, 2008 1:16 am|
|Matt Barber||Jul 31, 2008 1:24 am|
|Roman Haefeli||Jul 31, 2008 1:56 am|
|Matt Barber||Jul 31, 2008 3:29 am|
|Frank Barknecht||Jul 31, 2008 8:14 am|
|Hans-Christoph Steiner||Aug 1, 2008 1:48 pm||.pd|
|Luke Iannini||Aug 3, 2008 2:02 am|
|marius schebella||Aug 3, 2008 12:32 pm|
|Luke Iannini||Aug 7, 2008 11:36 pm|
|IOhannes m zmölnig||Aug 7, 2008 11:54 pm|
|Luke Iannini||Sep 19, 2008 4:53 am|
|Subject:||Re: [PD] declare [was: Re: Idiomatic Pd]|
|From:||marius schebella (mari...@gmail.com)|
|Date:||Jul 30, 2008 6:08:37 pm|
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)?
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....