On Nov 24, 2010, at 6:00 AM, Frank Barknecht wrote:
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 .] :)
Ah, I see, I totally didn't think of that use case. For me, this lib
has always been in the context of using my own patches, so I was
focused on solving the problems I've encountered there. It is also
totally useful to be able to use any object in these objects too.
I have two ideas on how to combine both approaches:
getdir, otherwise use the normal path
path $1]
Both are untested as of yet, but seem feasible.
.hc
If you are not part of the solution, you are part of the problem.