[PD] paths and patches [was: Re: polyWaveSynth issue]

Kyle Klipowicz kyleklip at gmail.com
Mon Sep 10 00:31:24 CEST 2007


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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>


-- 
-----
------------
    ----     -----
---- -------- - ------
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz




More information about the Pd-list mailing list