GEM-dev April 2005

gem-dev@lists.iem.at

11 participants
20 discussions

pf/pdp/3dp in Gem
by Tom Schouten 11 Aug '06

11 Aug '06

hi gemmers, just talking with jamie here in bergen and it's pretty clear to me how to write the bridge between libpdp and Gem. practicly, for me it is the build system. i'd like to add 5 objects. 3 of them are already in the pf/pd bridge. * [gem.get <thing>] : forks off one gemstate object as pdp packet * [gem.set <thing>] : inserts one pdp object in gem state * [pdp <thing>] : generic pdp processors (functional maps) * [3dp <thing] : 3d drawing objects (draw to current gl context) * [pf <script>] : any pf script the last 3 i have C code for and they don't depend on gem, but if pf/pdp/3dp is running inside Gem they need to be included. the first 2 need to be written from scratch as gem objects, possibly just derived from GemBase. i suggest someone helps me with setting this up, by adding templates for the gem.get and gem.set objects in the source tree and add them to the build process. the names are of course open to discussion. anything sane and short. the rest i need is just an init callback. this callback will: * initialize the forth and pdp memory manager * create the pf/pdp/3dp pd objects maybe it is best to keep this optional, since it introduces a library dependency. so, who is motivated to help me out here by adding the templates? i don't have time to learn the build and init process. cheers tom

10 62

Re: multiple_window: the questions begin!
by IOhannes m zmoelnig 16 Dec '05

16 Dec '05

james tittle wrote: > yallo, > > ...ok, checked it out and started compiling and stuff...immediately ran fine. > into a prob with the triggerMotionEvent(), which apparently takes four admittedly triggerMotionEvent (or rather: all of the hid-things like mouse, keyboard and probably tabled) does not really work yet in multiple_windows. we should discuss this (that is why i put this on gem-dev too): [gemmouse] outputs (as we all know) the mouse-position in the gem-window. now what happens if we have several gemwindows ? i think it there should be a mechanism to get the mouse-coordinates attached to the window the mouse appears in. this is not really possible with [gemmouse]. furthermore, [gemmouse] has several limitations (e.g.: no scroll-wheel support; what about mice with 10 buttons ?) now what should we do about it ? probably the simplest thing (as it is e.g. in pdp) would be to add an outlet to the various gem-windows that would emit the state of the mouse (or of any pointer). we could then build an abstraction (or do it in C) that sends this data to [gemmouse] which would act as a global receiver. as for outlets: personally i think by now(;-)) that it might be best to have just one outlet and prefix the outgoing messages, like [mouse <x> <y> <bt1> <bt2> <bt3>( this way we could always add another parameter to a certain message or just use a new message like [mouse_pos <x> <y>( [mouse_button 3 1( ok, the last 2 don't sound too convincing. anyhow, we need several messages to query things like the dimension of the window (or whatever): [dimen <x> <y>( > args: x, y, w, & h...why were the w & h added? I assume this is width > and height of the window that is being tracked? yes. the idea was to get away from absolute coordinates. i mean, you had to rewrite (well: adjust) your patch everytime you changed the window-dimensions (e.g. developping with a small window and performing with a big one) so i though normalized coordinates would be a cool thing (e.g. 0/0 is always upper left, 1/1 is lower/right) to make it compatible with older versions of [gemmouse] (else this would break every single patch that uses [gemmouse]) i decided to make this behaviour dependent on parameters. so you could give the maximum output range as arguments [gemmouse 1 1] would normalize x & y between 0..1 [gemmouse 10 20] would scale x between 0..10 and y between 0..20 ideally [gemmouse 1] would scale x&y between 0..1 on square windows and between 0..1 and 0..x/y (or the other way around ? thats the big question; i think i t would be better to fix the y-axis and scale x appropriately as this would make "moving objects with the mouse" much easier) on rectangle windows. mfg.as.dr IOhannes

5 16

Redundancy in PDP/Gridflow/Gem - was Re: [PD] gridflow for pd OS X(OT)
by B. Bogart 14 May '05

14 May '05

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(a)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(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

3 3

[re] pix_film on darwin ??
by Erich Berger 06 May '05

06 May '05

hi again, to specifiy it a bit: i was using in a workshop hans newest pd app which has a gem compiled from 13 april 2005 (i guess its cvs). in this version on a G4 desktop and G4 powerbook pix_film showed the following behaviour: - |auto 1( continuosly loops a loaded movie - there is no bang an the most right outlet when the movie is finished replacing it with the G4 version downloadable from the gem website does not help, behaviour stays like this. in windows and linux the behaviour is the following: - |auto 1( plays the movie once to the end - there appears a bang at the most right output of pix_film after when movie is finished any idea ? slimboy... reports its working on her machine ... best erich

3 5

Re: [GEM-cvs] Gem/src/Pixes pix_texture.cpp,1.29,1.30
by james tittle 04 May '05

04 May '05

On Apr 27, 2005, at 5:24 AM, IOhannes m zmölnig wrote: > Update of /cvsroot/pd-gem/Gem/src/Pixes > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7701 > > Modified Files: > pix_texture.cpp > Log Message: > set "state->texture" to "2", when using rectangle textures > don't overwrite "m_repeat" with "GL_CLAMP" when doing > rectangle-textures, as they will ignore that flag anyhow > ...hmm: just tried this, and it screws up osx texturing (makes a whole bunch of kinda sub-images: maybe not such a bad effect?)...and now looking at it, I'm not sure how these state->texture flags are supposed to work? In any event, it also underscores how complex this file has become :-\ jamie

2 3

Re: [GEM-cvs] Gem/src/Pixes pix_freeframe.cpp,1.2,1.3
by james tittle 29 Apr '05

29 Apr '05

On Apr 21, 2005, at 10:59 AM, IOhannes m zmölnig wrote: > Update of /cvsroot/pd-gem/Gem/src/Pixes > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23931 > > Modified Files: > pix_freeframe.cpp > Log Message: > initial support for loading plugins un windows and osX (still not > tested) ...ok, I've got this compiling on OSX now, and loading the plugin, but but it very quickly unloads because "no 24-bit support"...the relevent code here: if ((plugmain(FF_INITIALISE, NULL, 0)).ivalue == FF_FAIL){ error("plugin %s: init failed", name); return NULL; } // plugmain(FF_DEINITIALISE,NULL,0); if ((plugmain(FF_GETPLUGINCAPS, (LPVOID)FF_CAP_32BITVIDEO, 0)).ivalue == FF_TRUE){ if(can_rgba)*can_rgba=1; } else { if(can_rgba)*can_rgba=0; if ((plugmain(FF_GETPLUGINCAPS, (LPVOID)FF_CAP_24BITVIDEO, 0)).ivalue != FF_TRUE){ error("plugin %s: no %dbit support", name, 24); plugmain(FF_DEINITIALISE, NULL, 0); return NULL; } } ...is different than what I was using in a standalone OSX FF-host loader: if (pFreeFrameMain!=NULL) { pFreeFrameMain(FF_DEINITIALISE,NULL,0); if ((DWORD)pFreeFrameMain(FF_GETPLUGINCAPS,(void*)2,0)==FF_TRUE) { pVideoInfo->bitDepth=2; } else if ((DWORD)pFreeFrameMain(FF_GETPLUGINCAPS,(void*)1,0)==FF_TRUE) { pVideoInfo->bitDepth=1; } else if ((DWORD)pFreeFrameMain(FF_GETPLUGINCAPS,(void*)0,0)==FF_TRUE) { pVideoInfo->bitDepth=0; } else { assert(FALSE); pVideoInfo->bitDepth=2; } pFreeFrameMain(FF_INITIALISE,pVideoInfo,0); } ...so, having not really peered into the logic too much, are you trying have it only load if it does RGBA? l8r, jamie

2 1

GEM HD
by chris clepper 29 Apr '05

29 Apr '05

On Mar 1, 2005, at 11:27 AM, vade wrote: > > > BTW, we had 2 1080i DVCPro HD Streams running to 2 rects with barely a > frame dropped, with 3D transforms and all. Very.. very impressive.. You know I just figured out that the pixel packing for DVCPRO-HD is reversed from what we use in GEM. That causes a Quicktime routine to kick in which eats about 40% of my CPU here. It's only a change to two lines of code to get the proper format, but it would require all of the pix_objects to be rewritten! So looks like I may have guessed wrong back in Fall of 2002 when picking pixel formats. Oh damn. This could be something CoreVideo would sort out. cgc

4 5

pix_coordinate example crashes with curve3d
by B. Bogart 27 Apr '05

27 Apr '05

Hey all, Simply changing "square" to "curve3d" in the pix_coordinate example crashes PD due to gdb trace at end of this message. (PD 0.38-2 on OSX with Gem 0.90) 1. Create window 2. Load an image (I tired a number of JPG and TIF images) attached is the test-patch. I was really looking forward to using pix_coordinate to tile textures, any other way to do this? Thanks all. b> Program received signal EXC_BAD_ACCESS, Could not access memory. curve3d::render(GemState*) (this=0x784000, state=0xbffffb80) at src/Geos/curve3d.cpp:166 166 in src/Geos/curve3d.cpp (gdb) where #0 curve3d::render(GemState*) (this=0x784000, state=0xbffffb80) at src/Geos/curve3d.cpp:166 #1 0x03203d4c in GemBase::gem_renderMess(GemCache*, GemState*) (this=0x784000, cache=0xdb7, state=0xbffffb80) at src/Base/GemBase.cpp:80 #2 0x0320401c in GemBase::gem_MessCallback(void*, _symbol*, int, _atom*) (data=0x10f1020, s=0xdb7, argc=1, argv=0x3) at src/Base/GemBase.h:145 #3 0x00033364 in pd_typedmess (x=0x44b1d0, s=0x1, argc=18, argv=0x6) at m_class.c:749 #4 0x00034290 in outlet_anything (x=0x340d0ec, s=0xbffff0e0, argc=0, argv=0x44b1d0) at m_obj.c:445 #5 0x03203d84 in GemBase::gem_renderMess(GemCache*, GemState*) (this=0xbffff0c0, cache=0xdb7, state=0x44b1d0) at src/Base/GemBase.cpp:92 #6 0x0320401c in GemBase::gem_MessCallback(void*, _symbol*, int, _atom*) (data=0x10f1020, s=0xdb7, argc=1, argv=0x3) at src/Base/GemBase.h:145 #7 0x00033364 in pd_typedmess (x=0x44bfd0, s=0x1, argc=18, argv=0x6) at m_class.c:749 #8 0x00034290 in outlet_anything (x=0x340d0ec, s=0xbffff0e0, argc=0, argv=0x44bfd0) at m_obj.c:445 #9 0x03203d84 in GemBase::gem_renderMess(GemCache*, GemState*) (this=0xbffff2a0, cache=0xdb7, state=0x44bfd0) at src/Base/GemBase.cpp:92 #10 0x0320401c in GemBase::gem_MessCallback(void*, _symbol*, int, _atom*) (data=0x10f1020, s=0xdb7, argc=1, argv=0x3) at src/Base/GemBase.h:145 #11 0x00033364 in pd_typedmess (x=0x44b2e0, s=0x1, argc=18, argv=0x6) at m_class.c:749 #12 0x00034290 in outlet_anything (x=0x340d0ec, s=0xbffff0e0, argc=0, argv=0x44b2e0) at m_obj.c:445 #13 0x00033364 in pd_typedmess (x=0x44b2e0, s=0x1, argc=18, argv=0x6) at m_class.c:749 #14 0x00033364 in pd_typedmess (x=0x44b2e0, s=0x1, argc=18, argv=0x6) at m_class.c:749 #15 0x00034290 in outlet_anything (x=0x340d0ec, s=0xbffff0e0, argc=0, argv=0x44b2e0) at m_obj.c:445 #16 0x03203d84 in GemBase::gem_renderMess(GemCache*, GemState*) (this=0xbffff480, cache=0xdb7, state=0x44b2e0) at src/Base/GemBase.cpp:92 #17 0x0320401c in GemBase::gem_MessCallback(void*, _symbol*, int, _atom*) (data=0x10f1020, s=0xdb7, argc=1, argv=0x3) at src/Base/GemBase.h:145 #18 0x00033364 in pd_typedmess (x=0x44cdc0, s=0x1, argc=18, argv=0x6) at m_class.c:749 #19 0x00034290 in outlet_anything (x=0x340d0ec, s=0xbffff0e0, argc=0, argv=0x44cdc0) at m_obj.c:445 #20 0x00033364 in pd_typedmess (x=0x44cdc0, s=0x1, argc=18, argv=0x6) at m_class.c:749 #21 0x00033364 in pd_typedmess (x=0x44cdc0, s=0x1, argc=18, argv=0x6) at m_class.c:749 #22 0x00034290 in outlet_anything (x=0x340d0ec, s=0xbffff0e0, argc=0, argv=0x44cdc0) at m_obj.c:445 #23 0x03211b90 in gemhead::renderGL(GemState*) (this=0xbffff820, state=0x44cdc0) at src/Controls/gemhead.cpp:106 #24 0x03207238 in GemMan::render(void*) () at src/Base/GemMan.cpp:662 #25 0x000394e8 in sched_tick (next_sys_time=512860160) at m_sched.c:357 #26 0x000397b4 in m_scheduler () at m_sched.c:453 #27 0x000027b4 in _start (argc=0, argv=0x46db80, envp=0xbffffb80) at /SourceCache/Csu/Csu-47/crt.c:267 #28 0x8fe1a558 in __dyld__dyld_start () (gdb) bt #N canvas 415 336 794 470 10; #X text 452 8 GEM object; #X obj 8 335 cnv 15 430 80 empty empty empty 20 12 0 14 -233017 -66577 0; #X text 39 338 Inlets:; #X text 38 385 Outlets:; #X obj 8 296 cnv 15 430 30 empty empty empty 20 12 0 14 -195568 -66577 0; #X text 17 295 Arguments:; #X obj 7 76 cnv 15 430 210 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 449 77 cnv 15 170 250 empty empty empty 20 12 0 14 -228992 -66577 0; #X text 453 60 Example:; #X obj 474 344 cnv 15 100 60 empty empty empty 20 12 0 14 -195568 -66577 0; #N canvas 0 22 454 304 gemwin 0; #X obj 132 136 gemwin; #X obj 67 89 outlet; #X obj 67 10 inlet; #X obj 67 41 route create; #X msg 67 70 set destroy; #X msg 142 68 set create; #X msg 132 112 create \, 1; #X msg 198 112 destroy; #X msg 217 162 color 1 1 1; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 3 0 6 0; #X connect 3 1 5 0; #X connect 3 1 7 0; #X connect 4 0 1 0; #X connect 5 0 1 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X connect 8 0 0 0; #X restore 479 383 pd gemwin; #X msg 479 364 destroy; #X text 475 343 Create window:; #X obj 450 188 cnv 15 160 100 empty empty empty 20 12 0 14 -24198 -66577 0; #X obj 451 84 gemhead; #X text 71 31 Class: pix object; #X obj 510 85 bng 15 250 50 0 empty empty pix_load 20 8 0 8 -262144 -1 -1; #N canvas 0 22 587 366 image 0; #X obj 77 48 inlet; #X obj 77 344 outlet; #X obj 77 205 pix_image ../../doc/gem/examples/data/fractal.JPG; #X obj 223 55 inlet; #X msg 223 123 open \$1; #X obj 223 100 openpanel; #X connect 0 0 2 0; #X connect 2 0 1 0; #X connect 3 0 5 0; #X connect 4 0 2 0; #X connect 5 0 4 0; #X restore 451 113 pd image; #X text 63 306 <none>; #X text 56 398 Outlet 1: gemlist; #X text 63 352 Inlet 1: gemlist; #X text 516 105 open an image; #X text 509 118 (JPEG \, TIFF \, ..); #X text 50 12 Synopsis: [pix_coordinate]; #X text 13 76 Description: set the texture-coordinates for a pix; #X text 34 94 pix_coordinate remaps the S \, T texture values from the default values. For instance \, a texture could repeat by increasing the texture S \, T values from 1 \, 1 to 2 \, 2 (See the examples). ; #X text 63 367 Inlet 2: list: 8 values (4 (s \, t)-pairs); #X obj 538 144 loadbang; #X msg 461 237 \$1 \$1 0 \$1 0 0 \$1 0; #X floatatom 461 220 3 0 256 0 - - -; #X text 14 159 IMPORTANT NOTE-1: [pix_texture] sets the texture-coordinates to "appropriate" values \, so you probably want to use [pix_coordinate] afterwards; #X obj 10 207 cnv 15 420 70 empty empty empty 20 12 0 14 -225280 -66577 0; #X text 14 209 IMPORTANT NOTE-2: if your hardware supports it \, Gem tries to use "rectangle-texturing". This means that normal texture-coordinates range from 0..xsize (resp. 0..ysize). If it is not supported (or forced-off with "mode 0" to [pix_texture]) texture-coordinates range from 0..1 ; #X obj 451 266 pix_coordinate; #X msg 459 193 0 0 1 0 1 1 0 1; #X obj 451 296 curve3d 6 6; #X msg 467 167 mode 0 \, repeat 1; #X obj 451 136 pix_texture; #X connect 10 0 11 0; #X connect 11 0 10 0; #X connect 14 0 17 0; #X connect 16 0 17 1; #X connect 17 0 37 0; #X connect 27 0 36 0; #X connect 28 0 33 1; #X connect 29 0 28 0; #X connect 33 0 35 0; #X connect 34 0 33 1; #X connect 36 0 37 0; #X connect 37 0 33 0;

4 7

Re: [GEM-cvs] Gem/src/Pixes FreeFrame.h, NONE, 1.1 pix_freeframe.cpp, NONE, 1.1 pix_freeframe.h, NONE, 1.1 pix_imageInPlace.cpp, 1.4, 1.5
by james tittle 22 Apr '05

22 Apr '05

On Apr 20, 2005, at 1:31 PM, IOhannes m zmölnig wrote: > Update of /cvsroot/pd-gem/Gem/src/Pixes > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv1236 > > Modified Files: > pix_imageInPlace.cpp > Added Files: > FreeFrame.h pix_freeframe.cpp pix_freeframe.h > Log Message: > initial support for FreeFrame-plugins > currently i have only tested this on linux ...hmmm...I'm kinda torn on this: on the one hand, it's always nice to extend the capabilities...on the other hand, I don't see how we'll make yuv pathways available, much less the variable number of parameters... ...in case ya didn't know, the "pete's plugins" that I ported awhile back were originally freeframe plugins, but now they have been adapted to the pix_* system, and therefore have the ability to process rgba and yuv, plus they have help files...of course it's been awhile since I"ve kept up with the freeframe spec, so maybe things have changed (or maybe they should add yuv processing?)... ...also, most of the currently released freeframe plugins are not open-source, nor are they made available for non-x86 platforms (I don't even know if the commercial ones will work on linux)... ...so, I guess you can say I'm heavily skeptical of this, and cautiously indifferent! jamie

3 3

import stable snapshots to pure-data CVS
by Hans-Christoph Steiner 20 Apr '05

20 Apr '05

So I was thinking that it would be very handy to have stable snapshots of Gem in the pure-data CVS so that Gem can easily be compiled and included in the build system. The idea would be that whenever Gem has a stable release, we'll import the sources into the pure-data CVS. This will also be helpful with compiling gem2pdp and pgp2gem since we can set the build to use the Gem source from the pure-data CVS, where pdp2gem are already. I'll restrict access to the gem-devs and me (so I can do the importing). Then people can make branches if they want to work on Gem in the pure-data CVS. Any objections, comments, etc? .hc ________________________________________________________________________ ____ As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev April 2005