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@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list