GEM-dev March 2006

gem-dev@lists.iem.at

15 participants
34 discussions

Re: [GEM-dev] a few compilation problems
by IOhannes m zmoelnig 28 Mar '06

28 Mar '06

hi all. yesterday email at the iem had some problems, so i didn't get this email from matju; i found it in the gem-dev archives, so that's why my reply is so weird... <matju> ../Pixes/recordQT4L.h:22:18: error: lqt.h: No such file or directory i had to replace <lqt.h> by <lqt/lqt.h>. recordQT4L.cpp:23:26: error: colormodels.h: No such file or directory i had to replace <colormodels.h> by <lqt/colormodels.h>. </matju> no! giving the full path is not the correct way to handle it. actually lqt-config (or quicktime-config) should give the full include path and this should be added to the compiler flags, like "-I/usr/include/lqt" why? because the correct path depends on the distribution and quicktime version used. (it could as well be "/usr/include/quicktime" or somewhere else) <matju> In file included from pix_chroma_key.cpp:18: pix_chroma_key.h:15:25: error: GemFuncUtil.h: No such file or directory this is the problem that Peter Plessas had. He mentioned it on IRC #dataflow, which is why I tried compiling Gem today. I changed #include "GemFuncUtil.h" to "Base/GemFuncUtil.h". </matju> yes, this is a bug. i see that jamie has incorporated both changes, i'll revert the lqt one. mfg.asdr. IOhannes

1 0

a few compilation problems
by Mathieu Bouchard 28 Mar '06

28 Mar '06

../Pixes/recordQT4L.h:22:18: error: lqt.h: No such file or directory i had to replace <lqt.h> by <lqt/lqt.h>. recordQT4L.cpp:23:26: error: colormodels.h: No such file or directory i had to replace <colormodels.h> by <lqt/colormodels.h>. In file included from pix_chroma_key.cpp:18: pix_chroma_key.h:15:25: error: GemFuncUtil.h: No such file or directory this is the problem that Peter Plessas had. He mentioned it on IRC #dataflow, which is why I tried compiling Gem today. I changed #include "GemFuncUtil.h" to "Base/GemFuncUtil.h". _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

1 0

Re: [GEM-cvs] Gem/src/Base GemSIMD.cpp, NONE, 1.1 GemSIMD.h, 1.3, 1.4
by james tittle 27 Mar '06

27 Mar '06

On Mar 24, 2006, at 10:10 AM, IOhannes m zmölnig wrote: > > Modified Files: > GemSIMD.h > Added Files: > GemSIMD.cpp > Log Message: > implemented a small static class GemSIMD which is used to query the > SIMD-capabilities of the current CPUs: this should bring us away > from (not) using SIMD via preprocessors. ...this seems like a good thing (I'd like to also add a runtime check for g4 and g5 seperation...), but it's not working on this end atm... ...I'm a bit confused as to how it's supposed to work: "m_simd" is a static variable in GemPixUtil.cpp, but is also a member variable of GemPixObj(), or is it set up in GemMan? Should there be two checks like this, or has cvs gotten screwed up (really a whole topic)? ...in any event, I'll look into id'ing g3/g4/g5... jamie

2 3

[GEM-dev] Re: [GEM-cvs] Gem/src/Base GemPixConvertAltivec.cpp, NONE, 1.1 GemPixConvert.h, NONE, 1.1 GemPixConvertSSE2.cpp, NONE, 1.1 GemPixUtil.cpp, 1.48, 1.49 GemPixUtil.h, 1.46, 1.47
by james tittle 23 Mar '06

23 Mar '06

On Mar 22, 2006, at 7:59 AM, IOhannes m zmölnig wrote: > Modified Files: > GemPixUtil.cpp GemPixUtil.h > Added Files: > GemPixConvertAltivec.cpp GemPixConvert.h GemPixConvertSSE2.cpp > Log Message: > added SSE2-optimized RGBA2YUV conversion; > since GemPixUtil.cpp has grownso huge, i have outsourced the > optimized color conversion routines into separate files > GemPixConvertAltivec.cpp, GemPixConvertSSE2.cpp; obviously this has > only been tested on linux and mightwork (or not) on osx ...YAY!!! Thanks for taking this on, GemPixUtil was becoming incredibly unwieldy...also very exciting to see some SSE2 coming onboard (less for me to do when I get a macbook!)... ...I've got it compiling here after re-arranging some "code in progress" on my end, but I'm also going ahead moving the YUV422_to_YV12_altivec() from [pix_2pdp] into GemPixConvertAltivec.cpp...this requires a bit of a rewrite of the function interfaces, no prob, but it does bring up a question: How should we now require header inclusion to use this? Should we require GemPixConvert.h to be added, or should it just be automatically included via GemPixUtil.h? I ask this because pix_2pdp.h includes GemPixObj.h, which includes GemPixUtil.h, but that's currently not including the new conversion files... jamie

2 2

Re: [PD] GEM separator / pix_separator
by B. Bogart 23 Mar '06

23 Mar '06

Hi Sara and Johannes, Johannes, I'm testing your texcoords changes in CVS and things are looking pretty stable, PD has been using 861.2MB for over 24 hours and the patch has been running for 420:00.00 (hours?) of CPU time. Sara, maybe you can get a more recent build of Gem for OSX. Can you send a test patch of your [separator] bug? I might be seeing the same thing, but its hard to tell since I'm also dynamically sorting the gemhead render order... .b. sara kolster wrote: > Hi all, > > When using [separator] or [pix_separator], GEM displays the last created > [separator] chain in the foreground of GEMwin. Is there a possibility of > giving something like a set-message (used to set the render order of > gemhead) to give a order of rendering when using separator? > > Thanks a lot, > > Sara > > chris clepper wrote: > >> On 3/16/06, *sara kolster* <sara(a)x-i.net <mailto:sara@x-i.net>> wrote: >> >> Hi Ben, >> >> Thanks for your help. When I open the patch and turn rendering on, my >> terminal keeps spitting out the following message: >> >> /*separator : state->numTexCoords 4 != m_state.numTexCoords 0 >> >> >> You might have a separator object before a pix_texture which triggers >> that message. What it really means is that your patch is leaking >> memory and will eat all of your RAM soon. >> >> cgc >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> PD-list(a)iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > > > > > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

1 0

Importing gridflow's grid format in Gem
by Ivica Ico Bukvic 23 Mar '06

23 Mar '06

Hi all, I have started messing with the Gem/Gridflow interoperability. Thanks to Mathieu Bouchard I've learned about the #pix_import and #pix_export through which Gridflow can obtain contents of the Gem window and process them further. Where I am at a loss is when Gridflow processes image and outputs data in "grid" format, how to feed this back to Gem (regular pix format, or whatever that is, is easily returned back via #pix_import, but the "grid" format is giving me trouble)? The reason for this need is that I would like to maintain Gem window as the only visible window which contains both the output from Gem and Gridflow (i.e. a 3D cube with its faces textured with the output from the Gridflow). Attached patch sort of does that, but without any serious processing from the Gridflow's side (other than capturing the Gem window). The problem is with the part where the really interesting processing takes place in respect to the Gridflow, for instance object #remap_image. This object outputs a "grid" which I have no idea how to convert back to a format that can be imported back to Gem. All linking with Gem objects results in errors of various types suggesting that the two are obviously not compatible. Any help would be greatly appreciated! BTW, I am using Gem 0.90 and Gridflow 0.82 (on Linux). Best wishes, Ico #N canvas 125 6 729 655 10; #X obj 111 118 loadbang; #X obj 26 12 gemhead; #X obj 26 333 rotateXYZ; #X obj 35 310 #unpack 3; #X obj 35 253 # +; #X obj 60 253 t a; #X obj 35 272 #cast f; #X obj 35 291 # / (f # 100); #X floatatom 111 31 5 0 0 0 - - -; #X obj 79 12 bang; #X obj 111 12 fps \, period 5; #X obj 26 181 pix_texture; #X obj 248 411 #import_pix; #X obj 248 266 t a b; #X msg 287 266 snap; #X obj 248 318 pix_snap; #X obj 263 358 tgl 15 0 empty empty empty 0 -6 0 8 -241291 -1 -1 0 1; #X msg 263 372 yflip \$1; #X msg 35 234 30 21 15; #X obj 26 382 cube 4; #X floatatom 151 181 5 0 0 0 - - -; #X msg 270 391 help; #X obj 135 265 tgl 15 0 empty empty empty 0 -6 0 8 -24198 -1 -1 0 1 ; #X obj 152 264 metro 50; #X obj 26 140 pix_video; #X msg 111 140 driver 1; #X obj 100 498 gemwin; #X msg 110 363 create; #X msg 125 397 1; #X msg 134 432 0; #X msg 172 432 destroy; #N canvas 95 194 292 181 Gem.init 0; #X obj 83 30 loadbang; #X msg 161 76 reset; #X obj 134 146 outlet; #X obj 88 51 t b b; #X msg 45 75 dimen 400 400; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 3 0 4 0; #X connect 3 1 1 0; #X connect 4 0 2 0; #X restore 148 481 pd Gem.init; #X obj 608 309 #remap_image; #X obj 465 240 # -; #X obj 465 66 t a a a; #X obj 527 125 # % 2; #X obj 527 144 # * -2; #X obj 527 163 # + 1; #X obj 487 164 # *; #X obj 574 94 # / 2; #X obj 546 29 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -261681 -1 -1 0 1; #X obj 487 145 # -; #X obj 545 54 t f; #X obj 487 126 # %; #X obj 527 106 # /; #X obj 26 75 #export_pix; #X obj 25 206 translateXYZ 0 0 0; #X obj 249 16 gemhead 50; #X obj 336 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 351 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 390 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 405 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 336 76 #unpack; #X obj 389 76 #unpack; #X obj 326 233 #pack; #X obj 323 255 #export_list; #X obj 383 275 #export_list; #X obj 380 233 #pack; #X msg 336 56 128 128; #X msg 389 56 256 256; #X connect 0 0 25 0; #X connect 0 0 58 0; #X connect 0 0 59 0; #X connect 1 0 9 0; #X connect 1 0 45 0; #X connect 2 0 19 0; #X connect 3 0 2 1; #X connect 3 1 2 2; #X connect 3 2 2 3; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 7 0 3 0; #X connect 9 0 10 0; #X connect 10 0 8 0; #X connect 11 0 46 0; #X connect 12 0 11 0; #X connect 12 1 32 0; #X connect 13 0 15 0; #X connect 13 1 14 0; #X connect 14 0 15 0; #X connect 15 0 12 0; #X connect 16 0 17 0; #X connect 17 0 12 0; #X connect 18 0 4 0; #X connect 20 0 46 3; #X connect 21 0 12 0; #X connect 22 0 23 0; #X connect 23 0 18 0; #X connect 24 0 11 0; #X connect 25 0 24 0; #X connect 27 0 26 0; #X connect 28 0 26 0; #X connect 29 0 26 0; #X connect 30 0 26 0; #X connect 31 0 26 0; #X connect 32 1 34 0; #X connect 33 0 32 1; #X connect 34 0 33 0; #X connect 34 1 43 0; #X connect 34 2 44 0; #X connect 35 0 36 0; #X connect 36 0 37 0; #X connect 37 0 38 1; #X connect 38 0 33 1; #X connect 39 0 41 1; #X connect 40 0 42 0; #X connect 41 0 38 0; #X connect 42 0 39 0; #X connect 42 0 43 1; #X connect 42 0 44 1; #X connect 43 0 41 0; #X connect 44 0 35 0; #X connect 45 0 24 0; #X connect 46 0 2 0; #X connect 47 0 13 0; #X connect 48 0 54 0; #X connect 49 0 54 1; #X connect 50 0 57 0; #X connect 51 0 57 1; #X connect 52 0 48 0; #X connect 52 1 49 0; #X connect 53 0 50 0; #X connect 53 1 51 0; #X connect 54 0 55 0; #X connect 55 0 15 1; #X connect 56 0 15 2; #X connect 57 0 56 0; #X connect 58 0 52 0; #X connect 59 0 53 0;

4 8

Downgrading Quicktime
by B. Bogart 22 Mar '06

22 Mar '06

Hey Chris++, The OS X machine that runs the PD patch that is giving me the CPU troubles is also a video editing machine, so I'm wearly of changing back to QT 6 from 7 especially including our pro license. Is there a way I can leave QT7 installed for the video Apps, but also install QT6 only for Gem use? I also can't find where to download QT 6 from, apple only seems to give you the option for QT7 or the QT6 SDK. Any suggestions? Thanks, .b.

1 0

Re: [PD-dev] CVS update from today
by B. Bogart 21 Mar '06

21 Mar '06

Hi James, I'm moving this over to gem-dev. I did another update today and it does look like some changes got into anonymous. Note I'm compiling on Linux here. Now the build is failing with: g++ -c -fPIC -g -O2 -freg-struct-return -O3 -fno-builtin -falign-loops=16 -funroll-loops -ffast-math -mmmx -I/usr/X11R6/include -I/usr/include/ffmpeg -I/usr/include/quicktime -I/usr/include/avifile-0.7 -I/usr/include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/freetype2 rotate.cpp -o rotate.o glsl_program.cpp: In static member function 'static void glsl_program::linkCallback(void*, t_symbol*, int, t_atom*)': glsl_program.cpp:468: error: 'class glsl_program' has no member named 'm_wantLink' make[1]: *** [glsl_program.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/home/bbogart/pd-stuff/Gem.orig/src/Manips' make: *** [Manips] Error 2 But I do have ARB extensions: Result: Target : Gem.pd_linux Objects : Base Controls Geos Manips MarkEx Nongeos Particles Pi xes openGL Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -O3 -fno-builtin -falign-l oops=16 -funroll-loops -ffast-math -mmmx -I/usr/X11R6/include : -I/usr/include/ffmpeg -I/usr/include/quicktime -I/u sr/include/avifile-0.7 -I/usr/include/freetype2 INCLUDES : -I/usr/include/FTGL -I/usr/include/freetype2 DEFINES : LIBS : -ldv -lavformat -lmpeg -lmpeg3 -lquicktime -ljpeg -lt iff -lGLU -lGL -lXext -lXxf86vm -lXext -lX11 -ldl -lz -lm -L/usr/X11R6/lib -lp thread : -lGLU -lGL -lfreetype -lz -lftgl -laviplay -L/usr /lib -lquicktime -lgthread -lz -ldl -lMagick++ -lMagick LDFLAGS : -shared -Wl,-export-dynamic : -L/usr/X11R6/lib Strip : strip --strip-unneeded Install path : /usr/local pure-data: version : 0.38 used optional libraries: font-rendering : FTGL image-support use ImageMagick : yes use TIFF : yes use JPEG : yes video-support use mpeg : yes use mpeg-3 : yes use QuickTime : yes use aviplay : yes use ffmpeg : yes input-support use v4l : yes use ieee1394 : yes misc using ARB-extensions : yes using NV-extensions : yes using reg-struct-ret : yes Now run make ... I'll jump on IRC now to see if your are still around. .b. james tittle wrote: > On Mar 20, 2006, at 9:47 AM, B. Bogart wrote: > >> I did a update -dP today and looks like a lot has changed. > > > ...you may also want to update extensions/gem2pdp, because I've added > altivec code to pix_2pdp, which makes uyvy to yv12 color conversion a > non-issue, speed/cpu%-wise...so now if you use yuv textures on gem/ ppc, > you have a very quick round-trip to pdp and back... > >> I was able to compile the GLSL stuff before so I think this must be a >> bug: >> >> g++ -c -fPIC -g -O2 -freg-struct-return -O3 -fno-builtin -falign- >> loops=16 >> -funroll-loops -ffast-math -mmmx -I/usr/X11R6/include >> -I/usr/include/ffmpeg -I/usr/include/quicktime >> -I/usr/include/avifile-0.7 -I/usr/include/freetype2 -I.. >> -I/usr/include/FTGL -I/usr/include/freetype2 glsl_program.cpp -o >> glsl_program.o >> glsl_program.cpp: In member function 'void >> glsl_program::createArrays()': >> glsl_program.cpp:83: error: 'm_size' was not declared in this scope > > > ...snip... > >> Seems Patrick V had similar problems as well. > > > ...hmm: I just committed a fix (I hope)...seems that ya'll don't have > GL_ARB_shader_objects defined on the compiling machine? > >> I'm looking forward to testing the new [rubber] stuff and the new try at >> fixing the textcoords stuff. (Thanks Jamie & Johannes) > > > ...yep, I need to test that new texcoords stuff, too...but [rubber] is > much more useful, especially with multiple objects! Note that if you > set the spring message to 0 that you basically have a deformable > surface with memory 8-p... > > ...should have a nice example patch tonight: wanna meet on irc? > > jamie >

2 1

(no subject)
by B. Bogart 17 Mar '06

17 Mar '06

Hi Chris++ Here is another crack at showing my CPU problem. You'll need 16 different videos to test it. First change the makefilename and random numbers to reflect your video clips. Then start the patch with the big green bang. Then you can turn on the big green toggle to start the pause/unpause. It look 20min on this g5 dual 2Ghz with 1GB ram, so hopefully it will not take too much longer on your machines. I'm really at a loss for why this is happening, I've tried a smaller test with 3 videos and using a metro sending "rate" messages, but that has been playing for some time without an issue. Thanks Chris, Please let me know if your patch runs continuously on your machine for hours... .b..

2 7

(no subject)
by B. Bogart 17 Mar '06

17 Mar '06

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev March 2006