Hi all!
For the first time I'd like to use GEM (which I love) to do a kind of vj patch. So I'd like to preview files and stuff like that.
I was wondering if there's a possibility of associating a specific Gemwin to a specific Gem rendering chain, inside the same patch...?
With this I could create multiple Gemwins. so to preview situations and the shoot them to the final fullscreen monitor...
Thanks I.
Ivan Franco wrote:
Hi all!
I was wondering if there's a possibility of associating a specific Gemwin to a specific Gem rendering chain, inside the same patch...?
With this I could create multiple Gemwins. so to preview situations and the shoot them to the final fullscreen monitor...
hi, for now, Gem is limited to one single output-window. there is already some stuff in the CVS (branch: multiple_window) that allows multiple render-targets (e.g. windows); however, these will share the render chain (read: will render the same scene), but you can have different settings for each window (e.g. viewpoint,...)
mfg.ad.sr IOhannes
that would be very cool
motiondive has this feature
Also
is there a way to turn off sound in movies in 0.90?
On Monday, September 6, 2004, at 08:49 AM, Ivan Franco wrote:
Hi all!
For the first time I'd like to use GEM (which I love) to do a kind of vj patch. So I'd like to preview files and stuff like that.
I was wondering if there's a possibility of associating a specific Gemwin to a specific Gem rendering chain, inside the same patch...?
With this I could create multiple Gemwins. so to preview situations and the shoot them to the final fullscreen monitor...
Thanks I.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Patrick Pagano, B.S., M.F.A. candidate Research And Development Assistant Digital Worlds Institute University Of Florida (352) 294-2082
in fact those of you who know jitter or nato know how cool it is to be able to have monitors inside the patch itself. They can act like |print| (debugging data) only in this case with video streams.
of course it should be complicated using a tcl/tk interface but if we could just have multiple monitors floating around and picking part of a Gem processing stream...
Cheers all I.
On Sep 8, 2004, at 2:20 PM, shree wrote:
that would be very cool
motiondive has this feature
Also
is there a way to turn off sound in movies in 0.90?
On Monday, September 6, 2004, at 08:49 AM, Ivan Franco wrote:
Hi all!
For the first time I'd like to use GEM (which I love) to do a kind of vj patch. So I'd like to preview files and stuff like that.
I was wondering if there's a possibility of associating a specific Gemwin to a specific Gem rendering chain, inside the same patch...?
With this I could create multiple Gemwins. so to preview situations and the shoot them to the final fullscreen monitor...
Thanks I.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Patrick Pagano, B.S., M.F.A. candidate Research And Development Assistant Digital Worlds Institute University Of Florida (352) 294-2082
Ivan Franco I&D Director
ivan.franco@ydreams.com http://www.iilab.com/ivan/
YDreams SA http://www.ydreams.com
Disclaimer and Confidentiality Notice: YDreams accepts no responsibility or liability whatsoever with regard to the information herein contained. This message including any attachment hereof is confidential and may be privileged or otherwise legally protected from disclosure and may only be read, copied and used by the intended recipient. If you are not the intended recipient, please contact the sender immediately (+351 21 294 9683) and delete this email and any attachment permanently from your system. You must not copy this email or any attachment or disclose its/their contents to any other person or entity. Thank you. _________________________________
hi ivan...
if youre only thinking about doin some video stuff i would recommend framestein (well not really up to date... but for video stuff quiet ok). http://framestein.org/
it works with pd and is quiet easy to understand. it enables you to use some photoshop plugins for video processing und lets you build preview windows within the patches.....
regards wolfgang
At 17:37 08.09.2004, Ivan Franco wrote:
in fact those of you who know jitter or nato know how cool it is to be able to have monitors inside the patch itself.
...snip...
On Sep 8, 2004, at 10:37 AM, Ivan Franco wrote:
in fact those of you who know jitter or nato know how cool it is to be able to have monitors inside the patch itself. They can act like |print| (debugging data) only in this case with video streams. of course it should be complicated using a tcl/tk interface but
These are also big performance drains, which often outweighs their usefulness. I don't think any of the current GEM developers are going to try putting a GEM window in a patcher.
if we could just have multiple monitors floating around and picking part of a Gem processing stream...
This will probably be possible at some point, but there are other very interesting reasons for multiple render targets - things like rendering to surfaces and textures that we are really looking forward to having.
Also, speaking just for myself, I have no interest whatsoever in duplicating features from Nato, Jitter or other software at this point. I find those two Max video systems flawed in both technical and conceptual design, and do not wish to repeat their mistakes. The goal now is to incorporate designs that are fairly unique and not yet available in real-time artist oriented software. You can get an idea of some of these directions by checking out the latest branches in CVS or playing with Cyrille's excellent pmpd package. If you are really and truly seeking a standard A/B VJ style system then I would agree that GEM is probably not the best choice for such a thing, and you would perhaps be better served by the hundreds, if not thousands, of free and commercial softwares designed to do exactly that.
cgc
On Sep 8, 2004, at 5:48 PM, chris clepper wrote:
On Sep 8, 2004, at 10:37 AM, Ivan Franco wrote:
in fact those of you who know jitter or nato know how cool it is to be able to have monitors inside the patch itself. They can act like |print| (debugging data) only in this case with video streams. of course it should be complicated using a tcl/tk interface but
These are also big performance drains, which often outweighs their usefulness. I don't think any of the current GEM developers are going to try putting a GEM window in a patcher.
ok with that. Only I do believe they're useful since with floating windows it's common to get your display window behind your patch window (frontmost). You must always click on the Gemwin to get the big picture. With GOP Gemwins you can always be on the same frontmost window and debug really quick.
if we could just have multiple monitors floating around and picking part of a Gem processing stream...
This will probably be possible at some point, but there are other very interesting reasons for multiple render targets - things like rendering to surfaces and textures that we are really looking forward to having.
Also, speaking just for myself, I have no interest whatsoever in duplicating features from Nato, Jitter or other software at this point. I find those two Max video systems flawed in both technical and conceptual design, and do not wish to repeat their mistakes. The goal now is to incorporate designs that are fairly unique and not yet available in real-time artist oriented software. You can get an idea of some of these directions by checking out the latest branches in CVS or playing with Cyrille's excellent pmpd package. If you are really and truly seeking a standard A/B VJ style system then I would agree that GEM is probably not the best choice for such a thing, and you would perhaps be better served by the hundreds, if not thousands, of free and commercial softwares designed to do exactly that.
It's not about copying other features. As I said before I love Gem and did a lot of interactive stuff with it in the past. Only this time around I need previewing in a vj style. That's why I mentioned packages like Nato or Jitter. Also I don't intend to use other software since I know I have control using PD.
Sorry for the following comment but I'm a bit bothered about how people react when we talk about Max or Nato or Jitter or whatever software similar to PD/GEM/etc... I'm really supportive about opensource and I think it's the way to go, but I must mention something that seems good/practical, in my point of view, in those softwares. Not comparing or asking for features. Just commenting, since we all want GEM to grow to be more....
Cheers Ivan
cgc
Ivan Franco I&D Director
ivan.franco@ydreams.com http://www.iilab.com/ivan/
YDreams SA http://www.ydreams.com
Disclaimer and Confidentiality Notice: YDreams accepts no responsibility or liability whatsoever with regard to the information herein contained. This message including any attachment hereof is confidential and may be privileged or otherwise legally protected from disclosure and may only be read, copied and used by the intended recipient. If you are not the intended recipient, please contact the sender immediately (+351 21 294 9683) and delete this email and any attachment permanently from your system. You must not copy this email or any attachment or disclose its/their contents to any other person or entity. Thank you. _________________________________
On Wed, 8 Sep 2004, Ivan Franco wrote:
On Sep 8, 2004, at 5:48 PM, chris clepper wrote:
Also, speaking just for myself, I have no interest whatsoever in duplicating features from Nato, Jitter or other software at this point. I find those two Max video systems flawed in both technical and conceptual design,
It's not about copying other features. [...] Sorry for the following comment but I'm a bit bothered about how people react when we talk about Max or Nato or Jitter or whatever software similar to PD/GEM/etc... I'm really supportive about opensource and I think it's the way to go, but I must mention something that seems good/practical, in my point of view, in those softwares. Not comparing or asking for features. Just commenting, since we all want GEM to grow to be more....
Some references for you:
http://c2.com/cgi/wiki?NotInventedHere http://en.wikipedia.org/wiki/Not_Invented_Here http://www.ecotopia.com/webpress/nih.htm
And it's not because it is typically about corporations and research centres, that it can't apply to organisms, teams, and independent programmers too.
ttyl
Mathieu Bouchard http://artengine.ca/matju
On Sep 8, 2004, at 12:05 PM, Ivan Franco wrote:
Sorry for the following comment but I'm a bit bothered about how people react when we talk about Max or Nato or Jitter or whatever software similar to PD/GEM/etc... I'm really supportive about opensource and I think it's the way to go, but I must mention something that seems good/practical, in my point of view, in those softwares. Not comparing or asking for features. Just commenting, since we all want GEM to grow to be more....
That's a fair comment. The comparisons are fine, and I have made them before myself. However, I find it valuable to try to give some idea of what is going on in the development end, and give some idea of what we are attempting to do.
One of the basis for my previous comments is that I have found that most of the video systems around are for the most part exactly the same (along with their audio counterparts), and I do not see the need to make GEM into another one of those. It has some features that do set it apart, like being one of the few (only?) pure 3D systems, which need to be explored further.
Your request for multiple windows is a good one, and it will happen, but it is part of a larger project that goes beyond having some preview windows. At this point, the GEM developers are starting to not discuss development on the level of individual features and enhancements, but rather at the level of systems design and implementation. This seems to be very different from how most software is worked on, and I'm hoping it leads to a lot of new tools and solves some problems. There really is a vast area of ideas relating to video and graphics that haven't even been touched on by anyone working on this type of software. Right now, I want to explore these avenues rather than just coding up some more video plugins and adding more variants of existing features, which is unfortunately seems to be the most common path for software developers to take.
cgc
On Sep 8, 2004, at 2:37 PM, chris clepper wrote:
Your request for multiple windows is a good one, and it will happen, but it is part of a larger project that goes beyond having some preview windows. At this point, the GEM developers are starting to not discuss development on the level of individual features and enhancements, but rather at the level of systems design and implementation. This seems to be very different from how most software is worked on, and I'm hoping it leads to a lot of new tools and solves some problems. There really is a vast area of ideas relating to video and graphics that haven't even been touched on by anyone working on this type of software. Right now, I want to explore these avenues rather than just coding up some more video plugins and adding more variants of existing features, which is unfortunately seems to be the most common path for software developers to take.
...I agree here: GEM was originally written before most computers had hardware acceleration, somewhere around OpenGL 1.0? 3d seems to be GEM's greatest promise, all of the 2d image manipulation has been tacked on and enhanced since...my personal interest is in bringing GEM up to the modern OGL 1.5 implementations before anything else, really...
...otoh, just a thought: if we really wanted multiple windows (in patches or not) we may want to think about looking more into TOGL; it's a Tcl/Tk implementation of OpenGL: is anyone familiar with it? Or know of any attempts to use it as a GEM window? Due to my involvement with tcl/tk dev, I was asked to compile it for OSX, so that's laying around my HD somewhere...but then so is an unthinkably large number of other project starts ;-) In any case, TOGL seems to have minimal OpenGL capability (ie. 1.1 or so?), but we may just use it for the windowing...
hmm, james
Ok, just another general comment:
I personally think that one thing to keep in mind, concerning architecture/implementation on all of PD's visual externals, would be to have a nice performance of both visuals and audio running in the same PD patch. The most interesting thing about having both visuals and audio in the same app is to be able to drive both in parallel. It's just a bit frustrating when you have this beautiful Gem patch and then you throw some simple synthesis in and "click, drop, glitch"! Ugh....
This is a problem with all packages and I don't know the implications on the developing side. Just thinking out loud! :)
Cheers all and thanks for all your efforts! They are taken in account...
I.
On Sep 8, 2004, at 7:37 PM, chris clepper wrote:
On Sep 8, 2004, at 12:05 PM, Ivan Franco wrote:
Sorry for the following comment but I'm a bit bothered about how people react when we talk about Max or Nato or Jitter or whatever software similar to PD/GEM/etc... I'm really supportive about opensource and I think it's the way to go, but I must mention something that seems good/practical, in my point of view, in those softwares. Not comparing or asking for features. Just commenting, since we all want GEM to grow to be more....
That's a fair comment. The comparisons are fine, and I have made them before myself. However, I find it valuable to try to give some idea of what is going on in the development end, and give some idea of what we are attempting to do.
One of the basis for my previous comments is that I have found that most of the video systems around are for the most part exactly the same (along with their audio counterparts), and I do not see the need to make GEM into another one of those. It has some features that do set it apart, like being one of the few (only?) pure 3D systems, which need to be explored further.
Your request for multiple windows is a good one, and it will happen, but it is part of a larger project that goes beyond having some preview windows. At this point, the GEM developers are starting to not discuss development on the level of individual features and enhancements, but rather at the level of systems design and implementation. This seems to be very different from how most software is worked on, and I'm hoping it leads to a lot of new tools and solves some problems. There really is a vast area of ideas relating to video and graphics that haven't even been touched on by anyone working on this type of software. Right now, I want to explore these avenues rather than just coding up some more video plugins and adding more variants of existing features, which is unfortunately seems to be the most common path for software developers to take.
cgc
Ivan Franco I&D Director
ivan.franco@ydreams.com http://www.iilab.com/ivan/
YDreams SA http://www.ydreams.com
Disclaimer and Confidentiality Notice: YDreams accepts no responsibility or liability whatsoever with regard to the information herein contained. This message including any attachment hereof is confidential and may be privileged or otherwise legally protected from disclosure and may only be read, copied and used by the intended recipient. If you are not the intended recipient, please contact the sender immediately (+351 21 294 9683) and delete this email and any attachment permanently from your system. You must not copy this email or any attachment or disclose its/their contents to any other person or entity. Thank you. _________________________________
On Thu, Sep 09, 2004 at 12:46:20PM +0100, Ivan Franco wrote:
Ok, just another general comment:
I personally think that one thing to keep in mind, concerning architecture/implementation on all of PD's visual externals, would be to have a nice performance of both visuals and audio running in the same PD patch. The most interesting thing about having both visuals and audio in the same app is to be able to drive both in parallel. It's just a bit frustrating when you have this beautiful Gem patch and then you throw some simple synthesis in and "click, drop, glitch"! Ugh....
This is a problem with all packages and I don't know the implications on the developing side. Just thinking out loud! :)
it's because it is one of those invisible hard problems :)
because of the architecture of pd, there is no real way to solve this. i still think this is a very good thing, actually. pd's serial nature makes it simpler than a parallel approach.
you can solve this with threads, but then you somehow need to introduce the concept 'dropped frame' or similar and other synchronization methods.
when you run 2 pd's and try to get things working, you'll see some things are not 'real-time' any more, because there is a round trip delay between the 2 pd's, that is not predictable. that's about the problem you need to solve when adding a processing thread to pd.
not that it's not possible, it's just not so easy to do right. pdp has this (procqueue), but it's not actually working very well.
wvvw has this, and i think there it's working better. i'm still looking for the 'correct' approach.
cheers tom
On Wed, 8 Sep 2004, chris clepper wrote:
On Sep 8, 2004, at 10:37 AM, Ivan Franco wrote: Also, speaking just for myself, I have no interest whatsoever in duplicating features from Nato, Jitter or other software at this point. I find those two Max video systems flawed in both technical and conceptual design, and do not wish to repeat their mistakes.
Chris, Chris, Chris,
you see, the reason Jitter is so conceptually and technically flawed is that it got most of them concepts from GridFlow. So why don't you bitch about GridFlow instead? The original sin...! Authentic Evil! :-}
However one thing they didn't get from GridFlow is nested windows, something that GridFlow has gotten much later than most video plugins, though still earlier than, say, GEM or PDP...
Mathieu Bouchard http://artengine.ca/matju
On Wed, Sep 08, 2004 at 11:48:52AM -0500, chris clepper wrote:
This will probably be possible at some point, but there are other very interesting reasons for multiple render targets - things like rendering to surfaces and textures that we are really looking forward to having.
indeed. this is very interesting stuff. in principle it allows you to run the entire image processing engine with offline buffers or textures on the gpu.
i tried some of these with 3dp 0.12 but got into some problems with glx. however, doing multipass rendering to a part of the window does work. it is fast and it is standard GL, and used in a lot of 3d apps. the only problem with this is that it only works if the render window is on top.
chris clepper wrote:
On Sep 8, 2004, at 10:37 AM, Ivan Franco wrote:
These are also big performance drains, which often outweighs their usefulness. I don't think any of the current GEM developers are going to try putting a GEM window in a patcher.
actually it is somewhere on my to-do list (but with a *very* low priority) :-)) and i think the main target would be example-patches (and NOT previews)
(took some time to start answering this thread...)
mfg.a.sdr IOhannes
On Wed, 8 Sep 2004, Ivan Franco wrote:
in fact those of you who know jitter or nato know how cool it is to be able to have monitors inside the patch itself. They can act like |print| (debugging data) only in this case with video streams. of course it should be complicated using a tcl/tk interface but if we could just have multiple monitors floating around and picking part of a Gem processing stream...
GridFlow has unlimited windows open at once, including windows embedded in the patch. That latter feature, however, is Linux-only, and here's a demo of it:
http://gridflow.ca/gallery/peephole3.png
And yes, it's sucking CPU, but that's not a criterion of exclusion from GridFlow.
The only remaining problem, for you, is that GridFlow is not GEM.
Mathieu Bouchard http://artengine.ca/matju
Hi!
On Gridflow: I think it's also a great library but it's still missing the binary distribution (win/osx). This would really give extra value to gridflow since we know that most people are not into compiling. I gave up some kind of systems since I realized I spent more configuring than creating. This is true for all of us users. PD has really gained from the more recent efforts in the binary distributions/installers (thanks Hans). I know this is in your TODO list...
Cheers I.
On Sep 8, 2004, at 6:55 PM, Mathieu Bouchard wrote:
On Wed, 8 Sep 2004, Ivan Franco wrote:
in fact those of you who know jitter or nato know how cool it is to be able to have monitors inside the patch itself. They can act like |print| (debugging data) only in this case with video streams. of course it should be complicated using a tcl/tk interface but if we could just have multiple monitors floating around and picking part of a Gem processing stream...
GridFlow has unlimited windows open at once, including windows embedded in the patch. That latter feature, however, is Linux-only, and here's a demo of it:
http://gridflow.ca/gallery/peephole3.png
And yes, it's sucking CPU, but that's not a criterion of exclusion from GridFlow.
The only remaining problem, for you, is that GridFlow is not GEM.
Mathieu Bouchard http://artengine.ca/matju
Ivan Franco I&D Director
ivan.franco@ydreams.com http://www.iilab.com/ivan/
YDreams SA http://www.ydreams.com
Disclaimer and Confidentiality Notice: YDreams accepts no responsibility or liability whatsoever with regard to the information herein contained. This message including any attachment hereof is confidential and may be privileged or otherwise legally protected from disclosure and may only be read, copied and used by the intended recipient. If you are not the intended recipient, please contact the sender immediately (+351 21 294 9683) and delete this email and any attachment permanently from your system. You must not copy this email or any attachment or disclose its/their contents to any other person or entity. Thank you. _________________________________
-
--//-- -
chris clepper -
IOhannes m zmoelnig -
Ivan Franco -
James Tittle II -
Mathieu Bouchard -
shree -
Tom Schouten