this has been a problem for a long time. for instance, the counter object, which is in GEM and also cyclone (i think). regarding that object specifically, Pd's library loading is case specific, right? perhaps simply renaming the cyclone max-style object from "counter" to "Counter" would be a nice idea? it's something i've been thinking about... it's a hassle!! i never know which "counter" people are using when i use their patches...

Alex from idoia wrote:

Just open the C script in a text editor and search and replace 'limiter' by 'limiter_z' for exemple, then in the make file do the same and recompile, it should work. Alex

*From: *"Jordan J" <buck@defaced.net>
*Date: *Fri, 11 Apr 2003 19:17:35 -0500
*To: *"PD List" <pd-list@iem.kug.ac.at>
*Subject: *[PD] Objects with the same name.


I noticed that the Zexy library contains an object called limiter~.
 This object and the limiter~ external have the same object name so
when I try to load the limiter~ object I'm guessing it loads the one
that appeared in the pd startup command line first.  Is there a way
to use both without recompiling one or the other?  Renaming the
limiter~.dll doesn't work as I'm sure the actual object name is
defined with in the code.  Any help would be appreciated :/

-Jordan

------ http://USFamily.Net/info - Unlimited Internet - From $8.99/mo! ------

marius schebella schrieb:

AFAIK there is no defined searching order for objects. does the object, which is chosen depend on the order in which libraries are loaded during pd-start?

At least on Win it does. But I think on OS X it's not even possible to load two objects with the same name (but I'm not 100% shure about that). It just says:

/pd/bin/pd multiple definitions of symbol _scale_setup Gem.pd_darwin definition of _scale_setup maxlib.pd_darwin definition of _scale_setup

there could be a solution for the concerning objects, to use a name like c.counter, or cyclone.counter which should be a synonym for the counter object of the cyclone library.

This is my solution for the next (soon to come [maybe tomorrow]) maxlib release. Object names will then be maxlib_<oldobjectname>. This way if in doubt typing for example 'maxlib_scale' will make shure to use scale from maxlib, not from Gem. The old name swill still be an option to be backwards compatible and could be used as long as no problems occur. To make this work maxlib should be loaded as last library. This will (hopefully) also solve the problem in OS X because the setup routines now have different names.

still this would not tell anything about which counter people are using in their patches.

Neither does my solution in case people use the old names.... On the other hand I think we really should try not to brake old patches and to keep object names that are identical in Pd and Max.

Olaf