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
At 23:41 05.12.2007, 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. :)
MAX HAS SEGMENTED PATCHCORDS!!!!!!
scnr, sven.
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
On Thu, 6 Dec 2007, marius schebella wrote:
the most obvious and useful things are the tons of @arguments that each objects accepts.
Having tons of @arguments is not necessarily a blessing. Wherever Jitter has four @arguments named red,green,blue,alpha, GridFlow has only one, which is a list of the four colour components after a [#pack]. It makes GridFlow more structured than Jitter in this case, and that makes some objects more open to different colour spaces than Jitter's, in addition to yielding a better features-per-@arguments ratio.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
well, FYI in Jitter you do [jit.someobject @color r g b a] (for
example), or can use a message named color.
Ive never seen or used [jit.someobject @red r @green g @blue b @alpha a]
and jitter also has just about every colorspace conversion possible,
that I have ever seen or dealt with professionally, and many I have
not heard of or ever had to use:
http://cycling74.com/documentation/jit.colorspace
Not meant as flame bait (sorry, I still feel like an ass for yesterday
Mathieu!), but more for compare/contrast.
I quite like the attribute system jitter has, and think it could be
imported with some sort of syntax highlighting for objects where
attribute names are one color and their set values another.
It would (may?) help visually grokking the text within the patcher
object
On Dec 6, 2007, at 2:16 PM, Mathieu Bouchard wrote:
On Thu, 6 Dec 2007, marius schebella wrote:
the most obvious and useful things are the tons of @arguments that
each objects accepts.Having tons of @arguments is not necessarily a blessing. Wherever
Jitter has four @arguments named red,green,blue,alpha, GridFlow has
only one, which is a list of the four colour components after a
[#pack]. It makes GridFlow more structured than Jitter in this case,
and that makes some objects more open to different colour spaces
than Jitter's, in addition to yielding a better features-per- @arguments ratio._ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC
Canada_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 6 Dec 2007, vade wrote:
well, FYI in Jitter you do [jit.someobject @color r g b a] (for example), or can use a message named color. Ive never seen or used [jit.someobject @red r @green g @blue b @alpha a]
I forgot to say that it applies only to some of the classes in Jitter.
For example:
http://cycling74.com/documentation/jit.eclipse
I haven't looked at how many classes do it like that for the colours, but also some classes treat x and y axes as separate attributes instead of together, for example.
I quite like the attribute system jitter has, and think it could be imported with some sort of syntax highlighting for objects where attribute names are one color and their set values another.
So far I'm ok with the attribute system of GridFlow; Flext users seem ok with the attribute system of Flext; and the syntax is already mostly enough: the comma of GridFlow and the at-sign of Flext are distinctive enough. Colouring is not much of an addition because the text-based syntax of pd/max is too simple for that. (pd/max's syntax is more patch-based than text-based).
It would (may?) help visually grokking the text within the patcher object
"grok" should be reserved for what it originally meant, which is more intense than "understanding how it works", let alone "being able to parse the text". I'd love it if just the colours were enough to communicate the totality of the meaning of pd :} but it's not going to happen.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
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
You can do both within jitter, anything that is an attribute is by
virtue of being an attribute also a message - so you can send it via
loadbang, loadmess or whenever/however you want, so its up to you to
choose how you want your patch to work :)
On Dec 6, 2007, at 2:16 PM, Hans-Christoph Steiner wrote:
icely 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.
I also think that megaobjects that accept many messages/attributes
become more like application preferences rather than programming, and
that usually limits the possibilities. For example, in C, a function
with more than 5 parameters starts to get quite ugly and unwieldy.
In LISP, which Max's list handling is modeled after, it is also not
good form to have many attributes in a single function.
Objectclasses in object-oriented languages like Java, etc. accept
many messages, but I think that Max is more like a functional
language than an object-oriented one, (but somewhere in between).
I'm not saying I have the answer (yet? :) but this for me, thinking
about these kinds of things makes for a more intuitive and fluid
programming language.
(and when I say "Max" here, I am talking Max family, which includes Pd).
.hc
On Dec 6, 2007, at 2:38 PM, vade wrote:
You can do both within jitter, anything that is an attribute is by
virtue of being an attribute also a message - so you can send it
via loadbang, loadmess or whenever/however you want, so its up to
you to choose how you want your patch to work :)On Dec 6, 2007, at 2:16 PM, Hans-Christoph Steiner wrote:
icely 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.
All information should be free. - the hacker ethic
This is an interesting viewpoint -
"at what point does providing all of these options just get in my way
and make me not think about creating my own solutions - and thus
really really making it mine - while extending my knowledge"
Im not sure, I can tell you ive had to make plenty of my own solutions
with Max/Jitter - but I think you have a very valid point. There
certainly are a few assumptions on Jitters part that I do not
necessarily agree with.
Well said.
On Dec 6, 2007, at 4:10 PM, Hans-Christoph Steiner wrote:
I also think that megaobjects that accept many messages/attributes become more like application preferences rather than programming, and that usually limits the possibilities.
So now the next step is building a system that lets you have the ease
of jitter with the flexibility of Pd :D
.hc
On Dec 6, 2007, at 5:42 PM, vade wrote:
This is an interesting viewpoint -
"at what point does providing all of these options just get in my
way and make me not think about creating my own solutions - and
thus really really making it mine - while extending my knowledge"Im not sure, I can tell you ive had to make plenty of my own
solutions with Max/Jitter - but I think you have a very valid
point. There certainly are a few assumptions on Jitters part that I
do not necessarily agree with.Well said.
On Dec 6, 2007, at 4:10 PM, Hans-Christoph Steiner wrote:
I also think that megaobjects that accept many messages/attributes become more like application preferences rather than programming, and that usually limits the possibilities.
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
On Thu, 6 Dec 2007, Hans-Christoph Steiner wrote:
Objectclasses in object-oriented languages like Java, etc. accept many messages, but I think that Max is more like a functional language than an object-oriented one, (but somewhere in between).
On average, Pd/Max are more functional-or-procedural than OOP, because they tend to use OOP only as wrappers for indivual functions, decorated with methods that mostly just set arguments in advance. However they still offer the power to make bigger classes.
In Java, the tendency is to make big classes, plenty of methods. This is in part influenced by the rule that each public class has to be in a different file. People want to make a class worth the effort of having a separate file, so they design in a way that each class does more (unless they are paid by the number of files written!).
In some other languages, I may have a bunch of classes that are 5 lines long, perhaps even 1 line each. I may even be creating one class per iteration of a for-loop that processes a spec of a protocol or file-format. The class concept is not pedestalised and thus it is a concept that is more fluid, more integrated and less special.
I'm not saying I have the answer (yet? :) but this for me, thinking about these kinds of things makes for a more intuitive and fluid programming language.
Combinations of small objects are also good. (Java has also the problem of requiring the chaining of too many small objects some time. It's difficult to strike a balance between the two problems when your goal is to support everything at once)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Dec 6, 2007 10:46 AM, marius schebella marius.schebella@gmail.com wrote:
no real multitexture support for opengl. that is a must, if you want to work with shader languages like glsl.
Multitexturing works fine. The only drawback is that only texcoords from the texture unit in the chain with the shader can be used. This only presents a problem if the texture dimensions are different sizes.
this should be easily fixed by someone with sufficiant knowledge of the opengl world and gem (and time and resources...).
Unfortunately it is either not easy to fix or just beyond my abilities to do so. I have spent many, many hours trying to get this to work but cannot make it so.
I have no idea how complicated this stuff really is. from the user's viewpoint it looked like some lines of code, that needed to be added. and I know that it is even harder if you are alone in your problem solving... marius.
chris clepper wrote:
On Dec 6, 2007 10:46 AM, marius schebella marius.schebella@gmail.com wrote:
no real multitexture support for opengl. that is a must, if you want to work with shader languages like glsl.
Multitexturing works fine. The only drawback is that only texcoords from the texture unit in the chain with the shader can be used. This only presents a problem if the texture dimensions are different sizes.
this should be easily fixed by someone with sufficiant knowledge of the opengl world and gem (and time and resources...).
Unfortunately it is either not easy to fix or just beyond my abilities to do so. I have spent many, many hours trying to get this to work but cannot make it so.
-
Andrew Brouse -
chris clepper -
Hans-Christoph Steiner -
marius schebella -
Mathieu Bouchard -
sven -
vade