[PD] external search precedence

Hans-Christoph Steiner hans at at.or.at
Tue Apr 13 21:28:19 CEST 2010

Yes, that's right.  You can see more detail in this paper on libraries


4.3 Search order is also important
In an effort to make the library format as simple as possi-
ble, it is also necessary to consider the order that the library
paths are searched for a given name. Currently, Pd searches
each possible name through all of the paths before it tries
the next type. This means it is not possible to use the name
that binary ob ject has if that binary is included anywhere in
the search path. The binary always takes precedence, even
if someone sticks a Pd patch with that name in the same
folder as the pro ject (e.g. ".") While is it a good idea to
avoid name clashes, it is confusing if you create a patch with
a name, and then something else is loaded from the path.
With more and more Pd libraries being written in Pd (e.g.
abstractions), Lua, and other languages, we should consider
treating all of these implementation methods as equals.


On Apr 13, 2010, at 12:26 PM, Lorenzo wrote:

> Is it safe to say that pd will first look for a 'binary' external  
> (eg myext.pd_linux or myext.dll) and then for a .pd one (myext.pd)  
> and that in the former case the binary one will be used?
> Specifically I have a pd_linux and a dll version of a small (but  
> repeated a lot) external but not a mac one (havn't got a clue how to  
> compile it as I have no mac). So I thought of a .pd 'fallback' for  
> mac users. The idea is that opening the patch on a mac will use  
> the .pd version otherwise the platform specific binary.
> Thanks.
> Lorenzo
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


I hate it when they say, "He gave his life for his country."  Nobody  
gives their life for anything.  We steal the lives of these kids.  - 
Admiral Gene LeRocque

More information about the Pd-list mailing list