right now i'm writing a report on the effectiveness of Pd for use in
spatial audio. i'm also somewhat comparing it to its competition; csound, reaktor, and of course the various versions of MAX. it's been very hard trying to understand the current state of things, for example which is more widely used and has more people working on it?
i've read a lot about the various incarnations of MAX including jMAX,
MAX/MSP, Pd, and all the old stuff like MAX/Opcode, MAX/FTS, Patcher, ISPW stuff, etc.
have any of you tried several different things and have any useful
comparison info? how are the expansions in jMAX and MAX/MSP comparable to the expansions in Pd like GEM and GriPD? thanks,
scott
"640K ought to be enough for anybody." -- Bill Gates, 1981
I converted from Max to PD a couple of years ago. PD runs on any modern OS, it's free and the support is impeccable. Why anyone would continue to use Max is beyond me at this point. I think the only thing I missed was being able to create pretty, stand-alone applications but I got over that a long time ago.
Pall
On Monday 30 June 2003 20:43, J. Scott Hildebrand wrote:
right now i'm writing a report on the effectiveness of Pd for use inspatial audio. i'm also somewhat comparing it to its competition; csound, reaktor, and of course the various versions of MAX. it's been very hard trying to understand the current state of things, for example which is more widely used and has more people working on it?
i've read a lot about the various incarnations of MAX including jMAX,MAX/MSP, Pd, and all the old stuff like MAX/Opcode, MAX/FTS, Patcher, ISPW stuff, etc.
have any of you tried several different things and have any usefulcomparison info? how are the expansions in jMAX and MAX/MSP comparable to the expansions in Pd like GEM and GriPD? thanks,
scott
"640K ought to be enough for anybody." -- Bill Gates, 1981
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi, i've been using Max/MSP and PD for quite a while now and i see the following points:
Max:
- very good documentation and tutorials
- good patcher system which lets you create real user interfaces
- good configurable audio system with low latency
- OS9 version is quite unstable (or is (was!) it OS9?), OSX version is quite
ok.
- makes use of AltiVec on PPC
- Jitter is great
PD:
- it's free and open source
- very low latency for linux
- audio and midi system is often complicated to configure
- really bad user interface and documentation
The extendibility is in principle the same, although Max has more (but mostly commercial) packages. The support (due to the mailing lists) is equally good.
jMax has not had much success as it has been unstable and very sluggish due to its Java user interface. Version 4 has a different API which makes all externals written for older versions incompatible. However, it seems that the new jMax API is quite well-designed and can make use of multiple processors.
best greetings, Thomas
----- Original Message ----- From: "J. Scott Hildebrand" jshildebrand@ucdavis.edu To: pd-list@iem.kug.ac.at Sent: Monday, June 30, 2003 10:43 PM Subject: [PD] Pd vs. MAX
right now i'm writing a report on the effectiveness of Pd for use inspatial audio. i'm also somewhat comparing it to its competition; csound, reaktor, and of course the various versions of MAX. it's been very hard trying to understand the current state of things, for example which is more widely used and has more people working on it?
i've read a lot about the various incarnations of MAX including jMAX,MAX/MSP, Pd, and all the old stuff like MAX/Opcode, MAX/FTS, Patcher, ISPW stuff, etc.
have any of you tried several different things and have any usefulcomparison info? how are the expansions in jMAX and MAX/MSP comparable to the expansions in Pd like GEM and GriPD? thanks,
scott
"640K ought to be enough for anybody." -- Bill Gates, 1981
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
"J. Scott Hildebrand" schrieb:
i've read a lot about the various incarnations of MAX including jMAX,MAX/MSP, Pd, and all the old stuff like MAX/Opcode, MAX/FTS, Patcher, ISPW stuff, etc.
have any of you tried several different things and have any usefulcomparison info? how are the expansions in jMAX and MAX/MSP comparable to the expansions in Pd like GEM and GriPD?
There are severals pros and cons to all of them.
- jMax seems to have nearly no user base, on the mailing list only seem
to be developers and people with compile problems
- Max/MSP is easy to use and has very good documentation, runs stable
- Pd provides nearly the same functionallity as Max (regarding what you
can do with your audio signals) but to achieve the same results your patches look uglier and some 'missing' objects (mostly GUI ones) make some things more difficult to code / use
So from the user-only standpoint I would prefer Max. The very good documentation (several hundred pages manual) make getting started quite easy.
From the developer standpoint I would prefer Pd. It's easier to
understand how things could be done since you have access to Pd's sources which are - in a way - very good documentation for developers.
In the end it depends what you want to do with it. I haven't compared efficiency but it seems that Max/MSP runs slightly faster on a G3 with OS X than Pd does. The GUI reacts more smoothly and similar patches don't need as much CPU power as in Pd. And I have audio in with my Motu 828... ;-)
best, Olaf
Thomas and everybody else who's interested,
So what do you use the most and why?
Here are some specific questions based on what you wrote:
How does the Pd GriPd system compare to the patcher system for creating a good GUI inside of MAX/MSP? (AND is it possible in the future to use Pd as a signal processor in larger programs created with, for instance Fl/Tck in Linux or Visual C++ or Borland in Windows? It would be nice to use the processing and programming paradigm of Pd but interact with it via a pretty GUI in a larger standalone program.)
How does GEM compare to Jitter?
On Tue, 1 Jul 2003, Thomas Grill wrote:
Hi, i've been using Max/MSP and PD for quite a while now and i see the following points:
Max:
- very good documentation and tutorials
- good patcher system which lets you create real user interfaces
- good configurable audio system with low latency
- OS9 version is quite unstable (or is (was!) it OS9?), OSX version is quite
ok.
- makes use of AltiVec on PPC
- Jitter is great
PD:
- it's free and open source
- very low latency for linux
- audio and midi system is often complicated to configure
- really bad user interface and documentation
The extendibility is in principle the same, although Max has more (but mostly commercial) packages. The support (due to the mailing lists) is equally good.
jMax has not had much success as it has been unstable and very sluggish due to its Java user interface. Version 4 has a different API which makes all externals written for older versions incompatible. However, it seems that the new jMax API is quite well-designed and can make use of multiple processors.
best greetings, Thomas
----- Original Message ----- From: "J. Scott Hildebrand" jshildebrand@ucdavis.edu To: pd-list@iem.kug.ac.at Sent: Monday, June 30, 2003 10:43 PM Subject: [PD] Pd vs. MAX
right now i'm writing a report on the effectiveness of Pd for use inspatial audio. i'm also somewhat comparing it to its competition; csound, reaktor, and of course the various versions of MAX. it's been very hard trying to understand the current state of things, for example which is more widely used and has more people working on it?
i've read a lot about the various incarnations of MAX including jMAX,MAX/MSP, Pd, and all the old stuff like MAX/Opcode, MAX/FTS, Patcher, ISPW stuff, etc.
have any of you tried several different things and have any usefulcomparison info? how are the expansions in jMAX and MAX/MSP comparable to the expansions in Pd like GEM and GriPD? thanks,
scott
"640K ought to be enough for anybody." -- Bill Gates, 1981
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
"640K ought to be enough for anybody." -- Bill Gates, 1981
So what do you use the most and why?
When performing live (mostly improvising with musicians) i use Max/MSP because it gives me the possibility of designing good intuitive user interfaces without much effort. PD i currently use only for (often long-running) sound installations and development work. I normally write my externals (using flext) under Windows because it has the better development tools compared to the Mac.
How does the Pd GriPd system compare to the patcher system for creating a good GUI inside of MAX/MSP? (AND is it possible in the future to use Pd as a signal processor in larger programs created with, for instance Fl/Tck in Linux or Visual C++ or Borland in Windows? It would be nice to use the processing and programming paradigm of Pd but interact with it via a pretty GUI in a larger standalone program.)
Max/MSP can't currently compared to any of the PD GUI systems because it has much more possibilities. It would be possible though to push PD forward with only some externals, e.g. a simple lcd object for TCL/TK, which should be relatively easy to do. It _is_ possible to use PD embedded in other apps because it's only a shared library (or can be used as one). I'm currently developing a general performance system using PD as a faceless kernel.
How does GEM compare to Jitter?
I can't really comment on that since i don't know GEM very well.
From what i see is that Jitter is much more general and is extremely
well-designed. It seems to be a sum of GEM and PDP at least.
best greetings, T
At 2:51 +0200 1.7.03, Thomas Grill wrote:
How does GEM compare to Jitter?
I can't really comment on that since i don't know GEM very well. From what i see is that Jitter is much more general and is extremely well-designed. It seems to be a sum of GEM and PDP at least.
I would say its more the case of Jitter being a combination of nato.0+55 for Max, and Gridflow for PD. QuickTime plus matrix transforms. GEM is more of an opensource/x-platform video and graphics library for OpenGL stuff in PD. The MacOSX version of GEM could implement more QuickTime functions (thus making it more nato-like) but is bound by the limitations of GEM having to be cross platform, tending to make it a more 'OpenGL-only' kind of thing. I haven't used PDP (yet). nato's use of extensive qt functions (playlists, and much more) makes it the easiest way to do video related projects for me still. It is very direct generally, and has been very stable for me both in live and installation applications. Its implementation of QuickTime features still seems to be the most extensive.
That said, there are many more options now than there were when I started trying to use Max or PD for video.
This was one of the original motives behind GrIPD, that is, to make Pd stand-alone applications. It should be relatively straight forward to write up a shell script (on whatever OS), and have Pd launched with the proper command line args (-nogui, etc.) I came across this site:
and it looks like they are doing something along these lines with an altered version of GrIPD. Two things that I think might be helpful are 1) some kind of tool to help this process and 2) some sort of setup app that could detect hardware and let users set the settings, which could then write out a file with the proper command line args (audiodev, etc.) to launch the Pd-standalone with. Just two more items on my never-ending TODO list...
Joe jsarlo@ucsd.edu
How does the Pd GriPd system compare to the patcher system for creating a good GUI inside of MAX/MSP? (AND is it possible in the future to use Pd as a signal processor in larger programs created with, for instance Fl/Tck in Linux or Visual C++ or Borland in Windows? It would be nice to use the processing and programming paradigm of Pd but interact with it via a pretty GUI in a larger standalone program.)
hi Thomas,
for simple drawings/images/text
'tot .^.c <canvas-command>' -> [tot <destination-canvas>]
might do. Otherwise, tots stuffed with persistent scriptlets are more convenient.
Krzysztof
Thomas Grill wrote: ...
only some externals, e.g. a simple lcd object for TCL/TK, which should be relatively easy to do.
On Tue, 1 Jul 2003, Thomas Grill wrote:
How does GEM compare to Jitter?
I can't really comment on that since i don't know GEM very well.
From what i see is that Jitter is much more general and is extremely
well-designed. It seems to be a sum of GEM and PDP at least.
GEM and GridFlow to be more precise. Jitter follows the multidimensional data model formerly introduced by GridFlow, except it introduces a separate concept of channels ("planes"): in GridFlow, an image may be a 240*320*3 "grid", but in Jitter, it's a 240*320 "matrix" with 3 "planes". I'm not too sure what this additional concept is useful for, and it looks more like a hindrance to the generality of objects.
Mathieu Bouchard http://artengine.ca/matju
-
des1gner＠optusnet.com.au -
J. Scott Hildebrand -
Joseph A. Sarlo -
Krzysztof Czaja -
Mathieu Bouchard -
Olaf Matthes -
Pall Thayer -
Thomas Grill