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 <[EMAIL PROTECTED]> 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 > -- ----- ------------ ---- ----- ---- -------- - ------ http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list