[PD] mapping: path setting hell
cyrille.henry at la-kitchen.fr
Thu Apr 9 08:33:59 CEST 2009
Hans-Christoph Steiner a écrit :
> On Apr 8, 2009, at 5:59 AM, cyrille henry wrote:
>> Hans-Christoph Steiner a écrit :
>>> Inside of the objects themselves, I use always the [mapping/reverse]
>>> form. Only in the help patches do I use the [reverse] form. That
>>> convention seemed to make sense at the time, but I am not married to it.
>> since all mapping object are in the same directory, using the
>> [reverse] form inside the object will still work on pd-extended.
>> but it will also make the mapping lib more flexible (you'll be able to
>> move the objects / copy them in your patch directory ). So i see this
>> as a big improvement of the situation.
>> do you agree if i change this?
> Unfortunately, that's not entirely true, otherwise I would say to change
> it. Right now, a binary object will trump ANY abstraction, even if it
> is in the same directory. So if someone loads a binary object called
> "reverse", then [reverse] will ALWAYS be that binary, so matter where
> you put reverse.pd or how you load it. [mapping/reverse] prevents that.
name clash are bad.
curently it's a fact.
things may change in the future, but now nameclash must be avoid.
since there already are nameclash, it's important for a user to have a full control of the object used.
i do this by copying abstraction in my patch folder.
it also allow my patch to work latter, when the abstraction have changed.
> This is a perfect case of why we should change the load order in Pd.
change it if you wish.
but don't find workaround with solution that work only for you.
sorry if i'm rude, but i'm more and more irritated by this problem.
> think it should search for all object types in a given path (i.e. .pd
> .pd_linux, .pd_lua, etc.) THEN it should search the next path.
> Currently the opposite happens: it searches .pd_linux in all paths, then
> the loaders (i.e. .pd_lua) in all paths, then the abstractions in all
> "[W]e have invented the technology to eliminate scarcity, but we are
> deliberately throwing it away to benefit those who profit from
> scarcity." -John Gilmore
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
More information about the Pd-list