I took the advice of those here only to discover all copies of 0.37 involve me going into my terminal and using "./configure" to get the application executable.

I decided to regress to version .36 and got it to load, but recieved this message upon first open

//*

[12-224-175-158:~] enon% /Applications/Pd.command; exit could not open midi input device number 1: Invalid device ID. using default input device number: 0 using default output device number: 2 nchan 2, flags 3, bufs 8, framesperbuf 256 realtime setting failed because not root

*//

This doesn't sound good. Can somebody translate this form me?

I'd like to explore .37, could somebody used to installing it on OSX be kind enough to contact me privately for assistance? I'd be most appreciative.

btw - I'm using a M-audio quattro.

===== "Freedom is a hallucination created by a pathological lack of Paranoia"

Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

If you just want to get Pd running, then you don't need to compile it.
You can use the installer:

http://www.pure-data.org/downloads

click on "pure data", then download
"PureDataInstaller-0.37-2003.10.03.dmg." You will not need to open the
Terminal at all to get Pd working if you use the installer.

.hc

That's odd, this installer is the one I used initially which started this nightmare for me.

===== "Freedom is a hallucination created by a pathological lack of Paranoia"

Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

Congratulations to the OS X Installer, but I have a problem which is probably digidesigns fault (if you are not hooked on ProTools (I am) I strongly advise everybody not to invest in dizzydesign)

Of course it would be nice if it is possibly to use the Digi 002 with pd, as its sitting here and has obviously better and more converters than the G4 built in audio ;-)

But i get the following messages into the terminal when starting:

sh-2.05a$ /usr/local/bin/pd; exit DigiCoreAudioDriver> Found 10 entries in 'SupportedApps.txt'. Error number -9997 occured opening portaudio stream Error message: Invalid device ID.

When adding PD in the Digidesign Core Audio Setup application it tells me its selected already (but does not show it in the list)

Beside this problem, I have not found a very basic Documentation or Getting Started for PD. Whats listed at pure-data.org seems to be way too advanced or specialized. (Even for old Maxers as I am)

Best

Stefan

On Fri, 24 Oct 2003, marius schebella wrote:

I don't know jitter, but maybe pdp goes a bit into that direction? plz correct me!

I don't know what makes you believe that.

As far as Tom told me, PDP operates using a system of types. For each named type of data there is a way packets are constructed and a set of object classes willing to accept them.

GridFlow is less typed, as in, there is basically one data type, the Grid, and then it is parametrized by a list of nonnegative integers representing its size in each dimension, and a scalar number type (at the machine level, specifying bits-per-value and such: uint8 is 8 bits).

For example, Grid[240,320,3,uint8] would be a type in GridFlow (not that I actually use that syntax in the system itself). Usually, something of a size 240*320*3 could be assumed to be a RGB picture by the user, but technically, it can be anything, and most object classes actually don't give a damn. The user is supposed to know, and most users would only use RGB pictures most of the time, so they don't really have to ask themselves that question. But a Grid can also be used to represent other types of data, like:

• a polygon
• an indexmap (for morphing pictures)
• a colormap (palette)
• a whole series of pictures (a short movie loop or an icon collection)
• a dimension-list (representing the size of another grid)
• a single number (0-dimension grid: a scalar)
• emptiness (0-element grid)
• convolution matrix
• linear transform (change-of-axis) matrix
• and so on

And then some objects can work and are meaningful on all those kinds of data, even though those objects may not know what they are working on.

This is what GridFlow introduced as a new way of doing things back in the spring of 2001, and what Jitter reproduced [albeit with a bigger budget and better leverage] about a year later.

AFAIK, PDP has linear algebra functions, and actually is better at it than GridFlow, but those functions are separate from the picture processing, so for example in PDP you can't implement your own hue-shift effect by multiplying a picture by a matrix, whereas I'm doing exactly that in GridFlow. But maybe Tom can give you the exact details, as I am but a beginner with PDP.

Note: I don't know what NATO allows, and whether historically it's in the same streak as GridFlow. I never got to try, I never got to see it running, the company has disappeared, and its assumed author won't explain her design in a honest attempt to communicate. No matter what actually was available in the mysterious NATO, all my inspiration for GridFlow came from a 40-year old programming language called APL.

Mathieu Bouchard http://artengine.ca/matju

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

Hi Ben i am actually having a ball with GEM(g4) on my OSX box and using pix_video_ds on my winXP machine... linux is still too shaky for me with no way to get video in there. i am still at 7.3 on a sony vaio laptop and can't get ilink working and i just set up my SGIperformer stuff on there so i am not touching it alot of very cool stuff happening with vid in pd these days p.s. we just finished another global Access Grid perf with Korea/chile and indiana...dig http://apps.internet2.edu/

we have got to hook up pd with the AG

Pat

-----Original Message----- From: pd-list-admin@iem.at [mailto:pd-list-admin@iem.at]On Behalf Of B. Bogart Sent: Saturday, October 25, 2003 11:35 AM To: Patrick Pagano Cc: jhave@vif.com; pd-list@iem.at Subject: Re: [PD] GEM vs Jitter a newbie request for opinions

hey Pat,

I should have qualified my answer with, I use Gem almost exclusivly and I have little interest in using Jitter!!!

But you can do more technically with jitter than Gem, but a Gem-Gridflow working together would be really nice...

B. ----- Original Message ----- From: "Patrick Pagano" bigswift@ufl.edu To: ben@ekran.org Cc: jhave@vif.com; pd-list@iem.at Sent: Friday, October 24, 2003 2:06 PM Subject: Re: [PD] GEM vs Jitter a newbie request for opinions

Ben i have to disagree 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.

On Friday, October 24, 2003, at 11:54 AM, ben@ekran.org wrote:

...

Hey Jhave,

I've only tinkered with jitter, but I know a lot of jitter users. First off Gem is A LOT easier to learn than jitter. The way you patch is much more clear and intuitive. This is becuase there is no matrix operation stuff as there is in jitter. This makes Gem less powerful than jitter. What do you want to do with the video? Are you doing any matrix stuff at all?

For resources I just taught 120 college students Gem in two classes, 2 hours each. I have the lecture online at:

http://www.ekran.org/pd/PD-Lecture.tgz

It's an interactive PD patch so you should learn lots. Also Chris Clepper has some tutorials on his site at:

http://taproot.dyndns.org/~cgc/tutorial_gem/index.html

There are a large number of Graphics/Video libs for PD including: GridFlow (matrix operations), Framestein (windows only), PDP (something more like softVideo), and PiDiP (nice extra stuff on top of PDP), and of course Gem.

I just did a performance in collaboration with a jitter guy this week, I'll encode some video and have it online at some point in the next couple weeks. (Bottom line is they work well together, and there is a nice aesthetic balance)

Mathieu and Gem-devs: I've been doing a lot of matrix related stuff with Gem lately driven by my PSO object, and its a little awkward. (Like interpolating 24*8*5 vertex positions etc..) With Chris's vertex array stuff is there a possibility of using gridflow for matrix operations to be passed onto Gem for attaching to openGL? I would be very interesting in seeing such a connection. Are either party's interested? I have some example patches to show off what I mean by awkwardness if required!

Ben

...

Hello PD-gurus,

I'm a comp-sci student and artist just learning Max and PD, and i am beginning a project involving video,

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?

all comments appreciated,

jhave

---

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list