[PD] a flawed Gem (Was: Re: pdp/pidip on win32?)

[Hans-Christoph Steiner]

On Dec 20, 2008, at 4:03 PM, Claude Heiland-Allen wrote:

> John Harrison wrote:
> [snip]
>> And for me Gem also breaks many coding conventions of Pd.
>>
>> I'm not trying to trash Gem. I have the utmost respect for its
>> developers. I don't doubt it will be phenomenal with time and I  
>> wish to
>> support its continued development. But I am hesitant to recommend it
>> while it is in its current, perhaps unfinished, state. Example and  
>> test
>> patches work fine but outside of that realm my experiences have  
>> not been
>> positive. I have plans to document the problems I had and my thoughts
>> about the coding conventions. It's possible I'm misunderstanding some
>> things and/or maybe my concerns will help for future development.
>
> I agree - I'd also extend the hesitation to Pd itself but that's  
> another
> matter entirely.  I started writing a mail on a tangent to this topic
> (mainly sparked due to frustrations that verbose and boring C is nicer
> to work with than Gem for a project making heavy use of multipass
> rendering with shaders) a day or two ago, I'll just paste it here  
> in its
> current, perhaps unfinished, state:
>
> Hi all,
>
> Wondering if there are any plans for dataflow on the GPU in Gem?
>
> By this I mean that a patch cord would be a representation of pixel  
> data
> transfer paths on the GPU, and objects would process pixel data on  
> the GPU.
>
> I also do not mean using depth first message passing as a mechanism to
> shoehorn OpenGL state machine into Pd without concern for dataflow
> semantics (sorry if that sounds harsh - but it's the most
> counterintuitive aspect of Gem imo).
>
> Mainly I would want Gem to take care of allocating any temporary
> textures, binding/unbinding framebuffers + shaders, setting uniforms
> from inlets, etc, as it's a pain to do it manually (in any language).
>
> Would it make sense to make a set of "proof-of-concept" abstractions +
> shaders that port some subset of the pix_ objects to the GPU?
>
> Maybe this is all a bit too vague and I should do some research into
> other "dataflow on the GPU" environments, if there are any...

You guys should check out 3dp aka pdp_opengl.  I think Tom was trying  
to make dataflow+OpenGL feel more natural.  Or perhaps gridflow does  
opengl.

.hc

>
>
> Claude
> -- 
> http://claudiusmaximus.goto10.org
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list


------------------------------------------------------------------------ 
----

Access to computers should be unlimited and total.  - the hacker ethic