Wondering if there has been any exploration of any of the pdp/pidip objects in win32 ---- maybe even through cygwin.
Personal motivation: I'm teaching a class come mid-Jan where I'd like to incorporate pdp/pidip. Many of the students are on windows and it would be nice if they could do some development on their own machines.
-John
Hi John,
Well, I know what Yves' response to this will be ;-)
At any rate, I'd suggest GEM over PDP anyways, you can do most of the same things, it's truly cross-platform (i.e. has optimizations for each different architecture/processor, rather than PDP which is optimized for Linux + x86 only), it's much better documented and it's much more stable. According to the PDP and PiDiP authors, neither library will ever be ported to Windows.
best! Derek
John Harrison wrote:
Wondering if there has been any exploration of any of the pdp/pidip objects in win32 ---- maybe even through cygwin.
Personal motivation: I'm teaching a class come mid-Jan where I'd like to incorporate pdp/pidip. Many of the students are on windows and it would be nice if they could do some development on their own machines.
-John
Are you sure Gem is more stable? From my last project I feel very burned by Gem. I started coding the visuals 100% in Gem and through much pulling of my own hair gradually ended up redoing the project in pdp/pidip. The end result was stable (the Gem version wasn't --- multiple objects were crashing each individually tested and I had random freezes from different machines using Gem), looked a lot better, and used considerably less CPU resources. This was all in Linux.
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.
In terms of the Windows port idea of pdp/pidip, it's just a way for people to play around at home. I'm not concerned about optimization which is why I mentioned cygwin as an option. The final show will be on Linux machines, no doubt.
I'd hate to move out of the Pd environment for video but that may be my next step if this doesn't work out. Maybe Processing...
-John
Derek Holzer wrote:
Hi John,
Well, I know what Yves' response to this will be ;-)
At any rate, I'd suggest GEM over PDP anyways, you can do most of the same things, it's truly cross-platform (i.e. has optimizations for each different architecture/processor, rather than PDP which is optimized for Linux + x86 only), it's much better documented and it's much more stable. According to the PDP and PiDiP authors, neither library will ever be ported to Windows.
best! Derek
John Harrison wrote:
Wondering if there has been any exploration of any of the pdp/pidip objects in win32 ---- maybe even through cygwin.
Personal motivation: I'm teaching a class come mid-Jan where I'd like to incorporate pdp/pidip. Many of the students are on windows and it would be nice if they could do some development on their own machines.
-John
In such a case, why not turn them on to one of the many live CD Linux distros with Pd?
D.
John Harrison wrote:
In terms of the Windows port idea of pdp/pidip, it's just a way for people to play around at home.
I had the same idea. Problem is that the course is already "40 lbs of potatoes stuck in a 5 lb bag" as they say here in the midwest States. I may still go this route tho.
I'm a huge fan of Linux. While it improves at an astounding rate, still it can be rough to get Linux w/ 3D accel and sound guaranteed working on random hardware. And I can't afford lots of class time on that.
-John
Derek Holzer wrote:
In such a case, why not turn them on to one of the many live CD Linux distros with Pd?
D.
John Harrison wrote:
In terms of the Windows port idea of pdp/pidip, it's just a way for people to play around at home.
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...
Claude
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@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
On Sun, Dec 21, 2008 at 12:03:28AM +0000, Claude Heiland-Allen wrote:
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).
Also cool would be to have streams of geometry data flowing down the wires. In other words, an OpenGL scenegrapher for Pd. At the top of your chain you'd have a 'cube' object which would output the geometry for a cube every frame. Further down you would have geometry and colour and texture modifiers, and these would terminate in a [draw] object, which would render the resulting geometry. This is basically GEM flipped upside down.
This has been discussed on the list before but never went anywhere. Maybe I should talk less and code more. :)
Best,
Chris.
Just switch to linux and everything works better. pidip, GEM everything. I woudl love pdp/pidip to work on OSX completely too but people only seem to have so much time to devote.
pp
---- John Harrison john.harrison@alum.mit.edu wrote:
Are you sure Gem is more stable? From my last project I feel very burned by Gem. I started coding the visuals 100% in Gem and through much pulling of my own hair gradually ended up redoing the project in pdp/pidip. The end result was stable (the Gem version wasn't --- multiple objects were crashing each individually tested and I had random freezes from different machines using Gem), looked a lot better, and used considerably less CPU resources. This was all in Linux.
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.
In terms of the Windows port idea of pdp/pidip, it's just a way for people to play around at home. I'm not concerned about optimization which is why I mentioned cygwin as an option. The final show will be on Linux machines, no doubt.
I'd hate to move out of the Pd environment for video but that may be my next step if this doesn't work out. Maybe Processing...
-John
Derek Holzer wrote:
Hi John,
Well, I know what Yves' response to this will be ;-)
At any rate, I'd suggest GEM over PDP anyways, you can do most of the same things, it's truly cross-platform (i.e. has optimizations for each different architecture/processor, rather than PDP which is optimized for Linux + x86 only), it's much better documented and it's much more stable. According to the PDP and PiDiP authors, neither library will ever be ported to Windows.
best! Derek
John Harrison wrote:
Wondering if there has been any exploration of any of the pdp/pidip objects in win32 ---- maybe even through cygwin.
Personal motivation: I'm teaching a class come mid-Jan where I'd like to incorporate pdp/pidip. Many of the students are on windows and it would be nice if they could do some development on their own machines.
-John
-- John Harrison http://alumni.media.mit.edu/~harrison
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Patrick Pagano Sound and Light Technologist School of Theatre and Dance University of Florida
And have fun with the host of NIGHTNMARES that Vista provides. I teach/taught a digital design course using GEM/pidip and it was a nightmare. I gave extra credit for those who switched to linux.
---- John Harrison john.harrison@alum.mit.edu wrote:
Are you sure Gem is more stable? From my last project I feel very burned by Gem. I started coding the visuals 100% in Gem and through much pulling of my own hair gradually ended up redoing the project in pdp/pidip. The end result was stable (the Gem version wasn't --- multiple objects were crashing each individually tested and I had random freezes from different machines using Gem), looked a lot better, and used considerably less CPU resources. This was all in Linux.
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.
In terms of the Windows port idea of pdp/pidip, it's just a way for people to play around at home. I'm not concerned about optimization which is why I mentioned cygwin as an option. The final show will be on Linux machines, no doubt.
I'd hate to move out of the Pd environment for video but that may be my next step if this doesn't work out. Maybe Processing...
-John
Derek Holzer wrote:
Hi John,
Well, I know what Yves' response to this will be ;-)
At any rate, I'd suggest GEM over PDP anyways, you can do most of the same things, it's truly cross-platform (i.e. has optimizations for each different architecture/processor, rather than PDP which is optimized for Linux + x86 only), it's much better documented and it's much more stable. According to the PDP and PiDiP authors, neither library will ever be ported to Windows.
best! Derek
John Harrison wrote:
Wondering if there has been any exploration of any of the pdp/pidip objects in win32 ---- maybe even through cygwin.
Personal motivation: I'm teaching a class come mid-Jan where I'd like to incorporate pdp/pidip. Many of the students are on windows and it would be nice if they could do some development on their own machines.
-John
-- John Harrison http://alumni.media.mit.edu/~harrison
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Patrick Pagano Sound and Light Technologist School of Theatre and Dance University of Florida
bigswift@cox.net wrote:
And have fun with the host of NIGHTNMARES that Vista provides. I teach/taught a digital design course using GEM/pidip and it was a nightmare. I gave extra credit for those who switched to linux.
here in cairo installing lots of linux ( ubuntu hardy ).. there's no way back...
sevy
Derek Holzer wrote:
Hi John,
Well, I know what Yves' response to this will be ;-)
At any rate, I'd suggest GEM over PDP anyways
you can also know that we are friends with Iohannes and that there's no such competition between gem and pdp.
you can also know i did the bridge from gem to pdp,, pdp to gem..
but pdp has a few things than gem doesn't have, sorry ..
salam! sevy
-
bigswift＠cox.net -
Chris McCormick -
Claude Heiland-Allen -
Derek Holzer -
Hans-Christoph Steiner -
John Harrison -
ydegoyon