Nicely said, hopefully you can drum up more support for Gem. One
thing I think it really great about Gem is that is remains strongly
visual. When getting heavy into jitter, the patches look like you
are writing in C++ with boxes around it. What I would really like to
see is all those naming and attribute features represented in a
visual way, rather than just long lines of text like in Jitter. THen
if you want to write text-based code, you can use luagl, etc.
There are a lot of hidden secrets in Gem, you can do a lot with it.
For example, you can use all of the OpenGL primitives, check out Help-
Browser->examples->Gem->09.opengGL Just having better docs and
more examples would go a long way.
And I agree, Chris and IOhannes have been doing great work for a long
time, and I don't think it's properly recognized.
.hc
On Dec 6, 2007, at 11:46 AM, marius schebella wrote:
Hi Andrew, I use both. I am in a graduate class at brooklyn polytech, where josh goldberg teaches real time video interaction. it is an advanced class, and there are only 6 people, 3 of them are passionate
("professional"?) jitter users, and 2 people started using max in this program, but are also using other real time programs (or write their own C/Java/ whatever code) plus me. It is not a dedicated max class, but max gets the greatest support. I really tried hard to stay with Pd and do everything in GEM+...
but at some point this year I realized that GEM is not at all that highly developed as max and jitter. the most obvious and useful things are the tons of @arguments that
each objects accepts. then, with pwindow you always have small control windows inside your patch. all textures can be referenced by giving a @name attribute. you can switch easily between matrix computation
and gl world. you have better scripting support, plus more addons. the problem with gem, as I mentioned already on the list, is that it does not have enough developers. only iohannes and chris clepper are working on it, and it is more maintenance, than active developing. myself I am trying hard to get into GEM development, but it takes time until I know enough to be able to do that. the limitations of GEM at the moment are: no real multitexture support for opengl. that is a must, if you
want to work with shader languages like glsl. (jitter has that plus also javascript to combine the shaders, which in pd you have to do by patching.) this should be easily fixed by someone with sufficiant knowledge of
the opengl world and gem (and time and resources...). wesley, who is
also on this list, but also developing for c74, wrote the lua objects for jitter, and pdlua should be able to do equivalent stuff on pd-side for that (I am working to get it included into pd-extended.) I could
imagine that luagl people would rather use pd than max, because of open
source. on osx 10.5 the GEM window doesnot come to the front and does not
accept mouseclicks. I experienced problems with the colorspace on osx with some
pix_obects. on the other side jitter comes with a huge set of externals and abstractions. cv.jit is a great additional resource. but there are
tons... jitter has the more lively user community and you have more
developers.both programs lack of good vector graphics handling objects (like flash). this is a big lack in the open source world. a web savy open source replacement for flash!!!
still, my heart beats for the open source community, so I would
like to see gem and pd do the same things (and more) than max and jitter
can do. If you work in longtime installations you want to use linux and gem. opengl/gem on linux is faster than anything else (well at least faster than max/jitter). os x graphics drivers even limit some features of
the gfx card for compatibility reasons...for the next 3 years at least, gem will be behind, and if there are no new coders that will not change. I am not sure if this will change without money getting involved. the only other possibility to get
people involved is teaching pd/gem at college level. and get student programmers involved. or grab some money for gem development. google summer of code, or grants...above all that, there are all still the "obvious" pro/cons of max
vs pd. marius.Andrew Brouse wrote:
Hello Pd and Max folks,
I am doing a presentation (tomorrow!... so this request is a bit
late!) on differences between Max and Pd as tools for music and media art.I am interested in hearing:
from people who actively use both
about less-obvious advantages/disadvantages of one or the other
specifically about functionality for manipulation of video, OpenGL
including shaders and matricial data
- clear, reasoned, articulate thoughts and arguments as to why
one or the other is better or worse for one or another particular use ( why
should I expect anything else! ;)This could have some impact on decisions which will be made for a
project which I can't talk about yet. :)thanks for your help, Andrew
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli