Redundancy in PDP/Gridflow/Gem - was Re: [PD] gridflow for pd OS X(OT)

[B. Bogart]

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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20050429/df9fe5d1/attachment.pgp>