[PD] GEM vs Jitter a newbie request for opinions
chris clepper
cgc at humboldtblvd.com
Sat Oct 25 01:35:15 CEST 2003
>I have seen and used both and GEM (at least the G4 build) is
>amazing. i will try jitter again, but they seem to embody their
>names when it comes to quality.
>
Thanks. I think this discussion needs to define a few terms before
getting derailed (and potentially ugly).
At 11:33 PM -0400 10/23/03, JHAVE wrote:
>does anyone out there have any comments or suggestions
>on the relative learnability of Gem vs Jitter? (if so what resources exist?)
>and is Gem as powerful as Jitter?
First, what does the original poster mean by 'powerful'? If you mean
which is faster on OSX then GEM is demonstrably faster than Jitter on
current hardware (there's even a G5 version). I have measured the
two side by side and certain operations like texturing and image
processing in GEM are up to an order of magnitude faster than Jitter.
However if you mean which is potentially more flexible then Jitter
does offer access to data in a way GEM currently does not. That can
be both good and bad though. The more general the operation usually
the less optimization can be done on the code, and GEM has more
specific types of objects like pix_, for instance, which enable us
to write better code focused on speedy processing of image data and
not worry about 3D or generic data as well. Jitter has more low
level operations so you can build more customized patches and
processes which is great if you can't or don't want to write C
objects. GEM is getting a little more flexible, but I think the
structure of Pd/Max is probably too limiting for a truly flexible and
extensible environment. If you want that for video, I would suggest
building something around SuperCollider which would probably quite
easily top anything a Max based solution could produce. Another
option would be to embed some sort of scripting right into Pd/GEM
that would allow for things like :
5000.do(rotate(triangle(size,position.random),random(x,y,z))) which
would give you 5000 randomly positioned and rotated triangles. Try
that in _any_ of these current systems and you'll see why I'm
suggesting this alternative!
Which is easier to learn? Well if you have used Max/Pd for audio or
midi then GEM is probably easier because it follows Max conventions a
bit better. Also, GEM does not require the user to know anything
about it's internal data types. For the most part, I've found most
people really don't want to know that sort of thing and it's not
necessary for their work - they just want to manipulate video like
they do in other production applications or just like Pd handles
audio or MIDI. On the other hand, I now constantly field questions
about 'where are the matrices in GEM?' so I guess people are getting
used to it. Jitter comes with some fairly extensive examples and a
tutorial which is something GEM is just getting. The C74 people have
done a good job of 'selling' Jitter to the Max masses (but I won't
even mention the practices they now employ to back this up though),
and I've seen some nice work produced with it which is really the
only 'true' metric at the end of the day. So try them all and pick
which one(s) suit(s) best since the time invested will probably be
equal anyway.
cgc
More information about the Pd-list
mailing list