GEM-dev

gem-dev@lists.iem.at

2417 discussions

OSX building: configure & make?
by james tittle 17 May '05

17 May '05

hello, ...after upgrading to 10.4, I figured it would be nice to update the GEM project so that it would be more easily compiled, and this would mean to have xcode call an "external build system", which we already have in configure and make...unfortunately, right outta the gates configure isn't recognising the platform: tiggity:~/puredataDev/Gem/src/gnu tigital$ ./configure --with-ftgl creating cache ./config.cache uname: illegal option -- - usage: uname [-amnprsv] uname: illegal option -- - usage: uname [-amnprsv] HEAD: /usr/include /usr/local/include ../../../GemLibs/ LIBS: ../../../GemLibs/ /usr/local/lib /usr/local/src checking host system type... configure: error: can not guess host type; you must specify one tiggity:~/puredataDev/Gem/src/gnu tigital$ ...and I know little to nothing about configure scripts...so, I wonder if I shouldn't just make a specific "makefile.osx" and leave that in gem/src/gnu? If this is done, will it be able to detect new files as they are added, or do we have to also go ahead and change the makefile for each file added? jamie

2 6

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: [PD] [GEM] shadows and reflections
by B. Bogart 10 May '05

10 May '05

Hey Stefan, Zack Settle really wanted a spotlight with shadows, and got Pierre-Oliver Charlebois to write spot_light. Anyhow I have a test build for OSX for this, and attached is the source. It works ok, though the shadow edges can be little ugly. And for some reason the "lighting" switch does not work, when this object is compiled in lighting seems always to be switched on. I'm not sure if the author is on here, but the src files contain no log of changes for spot-light and the source looks just looks hacked from "world light" There is a little readme with no email contact. Anyhow here is it, I've done nothing with it but compile, maybe it can be added to gem proper... Anyhow Pierre-Oliver if your reading this please subscribe to gem-dev(a)iem.at and introduce yourself. As for reflections this seems pretty improbable in real-time.. I've been using something that looks something like reflection with pix_snap2tex feedback. I think most reflections done in real-time are faked. B> Stefan Turner wrote: > Hi list, > > Are any plans to implement shadows and reflections in > GEM? This has been asked a while ago, I'm just > wondering if things have changed since then. If not, > out of interest, what's the main problem with > implementing them, aside from being very CPU-heavy? I > think they would both be really cool features. > > Thanks > Stefan Turner > > > > ___________________________________________________________ > How much free photo storage do you get? Store your holiday > snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >

2 1

[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-dev] Redundancy in PDP/Gridflow/Gem - was Re: [PD] gridflow for pd OS X(OT)
by B. Bogart 04 May '05

04 May '05

Hey devs, The basis of my post was how we can work together. I think thinking beyond objects that pass data back and forth between the different systems. To repeat my example, Gem, PDP and Gridflow all have tracking objects/abstractions. All created independantly, probably having no code in common either. I'm just saying it makes little sense to have three complete packages that can all do the same things. Even if they do it in different ways. Better to work off the strength of one and other than reimplimenting similar ideas. Thanks all for me. B> shree wrote: > I think that what Ben and I might be after is a synthesis of these three > externals for a powerful image/video manipulation tool. > I see a tremedous potential for these three to act together and time and > development could be very advantageous. > > So with this in mind i think for me it might be most helpful, and jamie > may cringe but the bridge to and from pdp should flow both ways > pdp2gem & gem2pdp and would be powerful beginning tools > > and then the ability [IMHO] for all [pdp,gridFlow] to make use of the > GEM window probably exclusively or selectively. > > so in theory > > [gemhead] > | > [pix_video] > | > [pdp_stauration] > | > [gf] stuff] > | > [rectangle] > > could all be in a gemwin > > How much of this is possible, or reasonable i will simply ask > > > > Patrick Pagano, B.S., M.F.A. > Research And Development Assistant > Digital Worlds Institute > University Of Florida > (352) 294-2082 > > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

1 0

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

modified pix_buffer
by Florian Grond 04 May '05

04 May '05

Dear List, Lasse Scherffig and me have made a small change to the pix_buffer in GEM. With the message cyclic 1/0, you get a cyclic behavior of the buffer. Maybe it is worth considering to include. You find the sources and a testpatch here http://www-lehre.inf.uos.de/~lscherff/pdstuff/cyc_pix_buffer.zip. Cheers, Florian Grond

2 2

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev