[PD] Max & Pd

[Hans-Christoph Steiner]

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:
>>
>> 1. from people who actively use both
>>
>> 2. about less-obvious advantages/disadvantages of one or the other
>>
>> 3. specifically about functionality for manipulation of video, OpenGL
>> including shaders and matricial data
>>
>> 4. 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 at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list
>>
>
>
> _______________________________________________
> PD-list at 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