On Tue, Nov 23, 2010 at 01:23:44PM -0500, Hans-Christoph Steiner wrote:
On Nov 23, 2010, at 12:32 PM, Frank Barknecht wrote:
I didn't look in detail at how [getdir] is used, but for the rj poly objects we just require that the things you want to create dynamically are in your search path, just like for [polypoly]. I think, that's probably a reasonable assumption.
That's a dangerous assumption on anything but a small, tightly
controlled system. That takes us back to the bad old days when if you
used an external library, chances are your patch would not run on anyone else's machine.
If you create a poly-thing.pd file with e.g. [bundle 5 thing] in it, then the way you are currently using [getdir] it seems it will only find a thing.pd to load if it is in the same directory as poly-thing.pd. Creating for instance a [bundle 5 creb/blosc~] will not work, because creb/blosc~.pd_linux probably is somewhere else.
Now inside rj, we can poly-ize any object that you could manually create in your patch as a single separate object. This makes it very easy to patch something monophonic first, then later make it polyphonic by just changing your [s_rhodey] to [u_makepoly 8 1 s_rhodey]. This is *extremely* useful.
OTOH the only case, where objects cannot be created, is the case that you solve with getdir: abstractions that are right next to the surrounding patch (like poly-thing.pd and thing.pd from above) cannot be created immediatly because Pd extends its search path to the current directory only for the toplevel patches, not for abstractions used inside.
But to fix this is trivial and easy and portable: Just add [declare -path .] :)
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__