Ok, thanks for clearing that up Frank! It's a bit of a tangle, but you gave a nice explanation.
Messing with paths can be a real deterrence for people just looking to briefly demo a patch. It looks like the easiest solution for Phil is definitely to include these abs in a subdirectory then.
~Kyle
On 9/9/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Phil Stone hat gesagt: // Phil Stone wrote:
Kyle Klipowicz wrote:
Does Pd search the patch's folder first for all non-native objects before parsing the path?
I was wondering that same thing. If not, this method wouldn't work very consistently.
Pd does search the current directory of a patch before other directories, but that won't help polypoly.pd to find an abstraction in that directory, because polypoly.pd is in a different directory and there is no polywavesynth.pd there! To make polypoly.pd find polywavesynth.pd, the directory of polywavesynth.pd must be in the path!
Anybody still following? ;) I admit, that this is a very confusing issue, so lets use graphics and an example:
. |-- main | |-- an_abstraction.pd | `-- test.pd - uses [../main/using_an_abstraction] `-- myabs `-- using_an_abstraction.pd - uses: [an_abstraction]Assume, test.pd uses this object [../main/using_an_abstraction]. This itself is no problem as we use the object by a relative, fully qualified pathname. test.pd could also use [an_abstraction] of course.
However using_an_abstraction.pd also tries to use [an_abstraction] itself, but here this isn't found, as there is no "an_abstraction.pd" in "myabs" and Pd won't find the other one in "main" from here. This not only happens when using [using_an_abstraction] standalone, but also when it's used as an abstraction itself.
The exact same thing happens with polypoly.pd or singleton.pd when the objects, polypoly or singleton create, aren't in the search path for *polypoly* rsp. *singleton* itself, but somewhere else:
. |-- main | |-- CamelSynth.pd | `-- MySynthWithCamelWords.pd - uses [polypoly CamelSynth 24] `-- path_to_polypoly `-- polypoly.pd - is made to use [CamelSynth] above.Here [polypoly CamelSynth 24] tries to create a lot of [CamelSynth] objects, but those aren't found because there is no CamelSynth.pd in path_to_polypoly/. Duh. So "main" needs to be added to polypoly's search path which means adding it "main" to Pd's search patch or using [declare -path .] in MySynthWithCamelWords.pd
Also, this will all become resolved once Pd-extended moves forward to including more recent abstractions in its releases (i.e. Pd-extended-0.40 or however it will be branded).
Yes. (Hans? Frank?) please add sssad and polypoly to Pd-extended!
Isn't sssad already in pd-extended? Anyway, including them won't solve the problem above, as it's not related to polypoly rsp. singleton being reachable in your custom objects, but your custom objects being reachable for singleton or polypoly.
I'd recommend to make copies of singleton.pd and polypoly.pd into a subdirectory of polywavesynth and use them with local directory prefixes like [./_other/polypoly ...]
I do the same with singleton.pd in the subdirectory "_sssad" of sssad.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list