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