[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