[PD] gem library incompatibilites (zexy, motex)
zmoelnig at iem.kug.ac.at
Mon Aug 26 11:05:24 CEST 2002
João M Pais wrote:
> Dear list,
> 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
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
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
> João Miguel Pais
> PD-list mailing list
> PD-list at iem.kug.ac.at
More information about the Pd-list