[PD] mapping: path setting hell

[Hans-Christoph Steiner]

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.

This is a perfect case of why we should change the load order in Pd.   
I 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 paths.

.hc

----------------------------------------------------------------------------

"[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