Hey Pat,
I have not tried getting PDP or gridflow working on my g4 yet, I especially like how these three packages can work together. Right now there is a lot of functional overlap and I would guess a lot of duplicate efforts.
I just wanted to throw this out, even if I'm not a gem/pdp/gridflow developer.
For example video tracking, All three packages allow this functionality, all include objects to do so and some examples. (is there a Gem example? If not I have a nice simple one I can contribute.) For the Open Territories project (of which pixelTANGO is part) if the grant is a success we will be developing more streaming stuff and this would be great if it would fit in well into all three packages.
So the question is how to make the packages less redundant, how to play off the strengths of one and other...
Gem + YUV Video path (certainly on mac) very optimized, great video playback performance. + OpenGL, which means 3D as well as being able to capitolize on gamer industry features (shaders, gfx assembly, clusters, stereo etc..) - No the greatest pixel processing stuff, nor probably the best place for it?
PDP/PiDiP + Centrally a pixelprocessing tool and does it quite well. + Nice new streaming additions in PiDiP - 2D only, not as much optimization as Gem. (?)
Gridflow + Centrally a "grid" processing tool. + Mathematical control at a low level, probably the best way for a patcher (not external developer) to create tracking systems. + Grids need not be only images! - Seems not as well optimized (may be due to the fact that it is low-level pixel by pixel access)
So how could these things weave together in the future? I see a couple of possiblities:
* Gem for 3d, using PDP for pix_ processing. (Thanks to Jamie for making this a reality) How does the streaming stuff fit in? You could use the PiDiP streaming stuff to stream a texture, but I think we are a ways away from streaming the Gem buffer.
* Gridflow for Array processing. (that is anything that uses arrays, iemmatrix? and certainly some interesting low-level mathematical control of vertex-arrays. There are probably a few other things in Gem-land that could use something like gridflow as well.
Anyhow I realized this at pixelACHE and thought I would through it out. I think it makes little sense for someone to develop a IP streaming system that whose code cannot be used in Gem or gridlow. This is a big part of the piksel interoperability project @ bek.
Anyhow I'd love to hear some ideas about this issue.
B>
Patrick Pagano wrote:
Well i just have to say that without jamie, i would not even be able to comment, BUT.... big BUTT.
that was the most excitement i have had with the computer in a while
the examples are cool and i will gladly offer help to the next person as Jamie helped me
I think getting help, compiling it yourself makes you appreciate it so much more :-) after it works of course...lol
brought me back to ye Olde JMax days
GEM/pdp/gridflow .....Nice
On Apr 28, 2005, at 9:05 AM, Mathieu Bouchard wrote:
On Wed, 27 Apr 2005, Hans-Christoph Steiner wrote:
On Apr 27, 2005, at 6:52 PM, james tittle wrote:
On Apr 27, 2005, at 6:02 PM, Hans-Christoph Steiner wrote:
What's wrong with the ruby that's included with Mac OS X? At the very least, if a pre-compiled version of gridflow was included in the Pd.app, all the user would have to do is install Ruby.
The problem with the Ruby in OSX 10.2 is that it's just an application, that is, it's missing both libruby.a and libruby.dylib, and so gridflow.pd_darwin cannot embed the Ruby interpreter within PureData.
In OSX 10.3 and 10.4, the situation may be different, but I don't recall what it is. Anyhow, I think I recall that one has to install XCode to get Ruby, right? Does Pd.app already require XCode? I only have OSX 10.2 so someone else will have to look into it.
,-o---------o---------o---------o-. ,---. | | The Diagram is the Program (TM) | | ,-o-------------o--------------o-. `-o--------------o--------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone: +1.514.383.3801 `---' `-o-- http://artengine.ca/matju -'_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Patrick Pagano, B.S.,M.F.A Candidate Research And Development Assistant Digital Worlds Institute University Of Florida (352) 294-2070
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 29 Apr 2005, B. Bogart wrote:
PDP/PiDiP
- Centrally a pixelprocessing tool and does it quite well.
- Nice new streaming additions in PiDiP
- 2D only, not as much optimization as Gem. (?)
It has a module called 3DP which does OpenGL.
- Seems not as well optimized (may be due to the fact that it is
low-level pixel by pixel access)
I have no clue what you mean by that.
GridFlow works by global grid operations and not so much on a pixel-per-pixel basis.
Grid transmission is done in a cache-friendly way: unlike GEM and PDP, it cuts grids into small slices, and propagates one completely before sending the next one.
The biggest remaining speed issue is because there is still an awful lot of useless memory-copying going on, which is going to disappear Real Soon Now. (but it's not trivial to fix)
(There's actually an even bigger speed issue on Mac processors, but it's still a mystery to me.)
What I will need help on now, are bridges between PDP and GridFlow, and between GEM and GridFlow.
Who's willing to help ?
,-o---------o---------o---------o-. ,---. | | The Diagram is the Program (TM) | | ,-o-------------o--------------o-. `-o--------------o--------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone: +1.514.383.3801 `---' `-o-- http://artengine.ca/matju -'
On May 2, 2005, at 12:12 AM, Mathieu Bouchard wrote:
.
The biggest remaining speed issue is because there is still an awful lot of useless memory-copying going on, which is going to disappear Real Soon Now. (but it's not trivial to fix)
(There's actually an even bigger speed issue on Mac processors, but it's still a mystery to me.)
...me too :-\ But we'll see...I'm wondering if it's a "how floats are dealt with differently on x86 vs ppc"-kinda thing, but haven't checked it out much...
What I will need help on now, are bridges between PDP and GridFlow, and between GEM and GridFlow.
Who's willing to help ?
...uh, I've already started to work on a gridflow to gem imageStruct thing, in a similar manner as pdp2gem...but nothing to get too excited about yet...in part I think that the slowness of gridflow in osx atm may be due to the way it's just drawing to the window instead of using the faster path...using CGContextDrawImage() isn't normally used for video redraws...
jamie
On Mon, 2 May 2005, james tittle wrote:
On May 2, 2005, at 12:12 AM, Mathieu Bouchard wrote:
(There's actually an even bigger speed issue on Mac processors, but it's still a mystery to me.)
...me too :-\ But we'll see...I'm wondering if it's a "how floats are dealt with differently on x86 vs ppc"-kinda thing, but haven't checked it out much...
Huh? the problem happens even with integers. Floats are rarely used in GridFlow. Most of the meat is done using int32, sometimes dropping down to int16 and uint8 if I can. There is some support for float32, float64, but I haven't much of a use for them yet.
...uh, I've already started to work on a gridflow to gem imageStruct thing, in a similar manner as pdp2gem...but nothing to get too excited about yet...in part I think that the slowness of gridflow in osx atm may be due to the way it's just drawing to the window instead of using the faster path...using CGContextDrawImage() isn't normally used for video redraws...
Have you looked into that?
,-o---------o---------o---------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program (TM) | | ,-o-------------o--------------o-. `-o--------------o--------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone: +1.514.383.3801 `---' `-o-- http://artengine.ca/matju -'
-
B. Bogart -
james tittle -
Mathieu Bouchard