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



_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to