[PD] gem library incompatibilites (zexy, motex)

[IOhannes zmoelnig]

João M Pais wrote:
> Dear list,

hi !

> 
> I installed gem 0.87, and noticed that there are some objects that are
> repeated from other libraries, specifically average and scale (motex),
> change (default), abs~ (zexy 1.1).
 >
 > Are the objects from gem identical to the other ones? (at least they 
 > > seem)
 > If so, is there any advantage in using one instead of the other?

Gem was merged with markEX some years ago.
while Gem provided the graphics-engine, markEX was a useful collection 
of externals, like [change] and [abs~]

some of these (markEX) externals were so useful, they made it into the 
main-distribution, noteable [change].
others were not SO useful, but still needed by lot's of people, who 
didn't want to include the huge Gem-library all the time they needed 
(say: ) basic signal operations, like [abs~]. so they included it in 
their private libraries. [abs~] from zexy is an example for this.

[average] is a similar case. while i do not know, what is the behaviour 
in the motex-version, i do know, that there is the [mavg] (Moving 
AVeraGe) object in zexy, which does quite the same (although it is a bit 
more dynamic).

that's the good news (name clashes with objects that do the same)
now the bad news:

[scale] is a basic Gem-object, that allows you to scale (sic!) a Gem-geo 
(like a model, cube, square, etc.)
i am sure no other external/library (like motex) will be able to provide 
the same functionality. (i am sure other libraries could be able (like 
gemee) but i leave it like this)


however, we have a problem (which was discussed before)
in terms of fairness we have to apply a "first comes, first served" rule 
on name-clashes.
Since Gem (and the old markEX) were the very first (public available) 
libraries (as is see it, having played with pd since about 0.20),
and Gem is really a world of it's own
nobody should use object-names that have been introduced by Gem long ago 
  for different functionality (which is *very* likely in the case of Gem),
however unappropriate (or general) the name seems for the 
Gem-functionality and however fitting it would appear for the new function.

to avoid nameclashes with (at least) Gem (and a few other libraries) we
could either restart the discussion on namespaces in pd or look at the
pure-data-base @ http://pd.iem.at/pdb
Since the number of libraries have been exploding in the last year,
this data-base is kind of un-maintainable for a single person (like me - 
at least at my current working-conditions ;-), and therefore should be 
made writeable by the community (which i would have to do)


> To decide which library to use, pd works with the libraries first loaded, so
> I put gem as the last library on my list.

which might render Gem unusable.
however, it is your decision. but maybe it would be a better idea to 
load libraries on demand rather than all the time.
to make this more useable, it might be a good idea (just brainstorming!) 
to introduce a "-nolib" flag, which would prevent a library priorly 
specified with the "-lib" flag to be loaded at start-up.
So you could have a .pdrc that loads (say) motex but not Gem, and, if 
you wanted to use Gem you could start pd with "pd -nolib motex -lib Gem" 
to avoid the [scale] nameclash.
of course very unsatisfactory



mfg.cd.asr
IOhannes

> 
> 
> João Miguel Pais
> 
> 
> _______________________________________________
> PD-list mailing list
> PD-list at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
>