[PD] Re: GEM/maxlib scale problem

[Olaf Matthes]

Hi Chris and list,

well, I know that this nameclash exists. But I don't know what to do....
maxlib's scale is identical to the scale in Max (but scale is not a
native Max object, I think) so it makes sense to keep it's name for
compatibility reasons. On the other hand Gem's scale has been introduced
earlier and is used in quite a lot of patches, I guess.

I could add an option to maxlib that would prepend all the object names
with 'maxlib_' to avoid nameclashes. But this could only be included
during compilation and would produce quite long object names. And leaving
it an option one would need to know which version was used for a patch
before being able to open it.

The problem we're facing here is not the only one where nameclashes
occur. On thursday Eric Skogen posted a mail to the list asking for help
with a similar problems. I'll also post this mail to the pd list since we
had this discussion several times but never really got to a definite
solution, I think. Or did I miss anything?

Olaf

PS: the error message is OS X only, Linux and Win just ignore the second
definition and create the object that has been loaded first... maybe
there is an option that can be set to ignore this error and to force the
behaviour found on Linux?


chris clepper schrieb:

> Hi Olaf
>
> I was just talking to a Gem beta tester who mentioned that there is a
> multiple definition of symbol _scale_setup when using both Gem and
> maxlib.  Maxlib seems way too useful to have to choose between it and
> Gem.  Has this been brought up before??
>
> errors:
>
> /pd/bin/pd multiple definitions of symbol _scale_setup
>   Gem.pd_darwin definition of _scale_setup
> maxlib.pd_darwin definition of _scale_setup
>
> cgc