Re: [PD] Obscure pd externals in search path shadow .pd files in current working directory

2007-09-01 Thread Miller Puckette
Hi Julius, I think that seq isn??t getting shadowed (the patc's directory is always searched first) but rather, that once an extern is loaded of a certain name, Pd no longer searches for abstractions of the same name. It's as if you tried to name an abstraction float or something -- C objects,

Re: [PD] Obscure pd externals in search path shadow .pd files in current working directory

2007-09-01 Thread Stephen Sinclair
There should be some way in Pd to throw out objects by name... I'm still trying to figure out how to deal with name conflicts so that nobody ever gets burned :) In a way it might be nice to have some concept of namespaces, such that objects can be referred to simply by name, or alternatively

Re: [PD] Obscure pd externals in search path shadow .pd files in current working directory

2007-09-01 Thread Hans-Christoph Steiner
This is addressed in the Pd-extended distribution. Every library is compiled so that each class is compiled as it's own file (i.e. [counter] = counter.pd_linux) instead of having multiple classes in one file. Functional namespaces already exist in Pd. This feature is used extensively

[PD] Obscure pd externals in search path shadow .pd files in current working directory

2007-07-27 Thread Julius Smith
Hi All, In figuring out why seqdemo.pd did not work (in the cool faust/tools/faust2pd/examples distribution), I discovered that the local file ./seq.pd was being shadowed by /usr/lib/pd/extra/cyclone/seq.pd_linux. It appears that, due to search order, all externals, wherever they may reside in