Yes, that's right. You can see more detail in this paper on libraries http://at.or.at/hans/Let%27s_Make_Libraries_-_PdCon3.pdf

Specifically:

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.

.hc

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@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