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

Miller Puckette mpuckett at imusic1.ucsd.edu
Sat Sep 1 16:13:28 CEST 2007


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, internal or external,
essentially become keywords.

A possible workaround would be not to load the library containing seq (and
in general, perhaps it's best not to load any that you aren't actively using).

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 :)

cheers
Miller

On Fri, Aug 31, 2007 at 12:09:13PM -0700, Julius Smith wrote:
> 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 the search
> path, take precedence over .pd files, even those in the current working
> directory.  It seems to me both externals and subpatches in the cwd
> should take precedence over the rest of the search path. Also, I would
> expect subpatches to take precedence over externals in the same
> directory (with a warning about the shadowing printed to the console).
> 
> My workaround, by the way, was to rename seq.pd to seqr. pd in the
> seqdemo directory. 
> 
> Cheers,
> Julius
> 
> 
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list




More information about the Pd-list mailing list