hello,

this windows build is to late for me but a friend tested it on 2 differents computer (pd 38.2 + winXPpro sp2). gem does not load because glew32.dll or MSVCP71.dll is missing.

i've found a stable wifi spot, so i made a cvs update. for now : pix_record does not compile on my system. (and never did) (still using ubuntu breezy)

pix_record.cpp: In constructor ‘pix_record::pix_record(int, t_atom*)’: pix_record.cpp:55: erreur: cannot allocate an object of abstract type ‘recordQT4L’ ../Pixes/recordQT4L.h:38: note: because the following virtual functions are pure within ‘recordQT4L’: ../Pixes/record.h:73: note: virtual int record::putFrame(imageStruct*) make[1]: *** [pix_record.o] Erreur 1

exept that, my list of "bug" that could be fixed :

pix_write write images upside down in .jpg, but images are correct in .tif

there was a discussion about making remanence effect with alpha for the gemwin background. i noticed some change was made on the source code to allow alpha in the background color, but i still not able to make it work.

that's all for me.

thanks Cyrille

ps : my ./configure... cyrille@nusmuk:~/pd/Gem/src$ ./configure checking for Base/configLinux.h.in... yes checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for sin in -lm... yes checking for main in -lz... yes checking for dlopen in -ldl... yes checking how to run the C preprocessor... gcc -E checking for X... libraries /usr/X11R6/lib, headers in standard search path checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for main in -lX11... yes checking for main in -lXext... yes checking for XF86VidModeGetAllModeLines in -lXxf86vm... yes checking for main in -lXext... (cached) yes checking for glInitNames in -lGL... yes checking for gluLookAt in -lGLU... yes checking for "OpenGL"-framework... no checking for "AGL"-framework... no checking for "Carbon"-framework... no checking for "QuickTime"-framework... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for PKG_IMAGEMAGICK___CFLAGS... checking for PKG_IMAGEMAGICK___LIBS... -lMagick++ -lMagick checking for PKG_TIFF_CFLAGS... checking for PKG_TIFF_LIBS... checking for tiff-config... no checking for TIFFOpen in -ltiff... yes checking for PKG_JPEG_CFLAGS... checking for PKG_JPEG_LIBS... checking for jpeg-config... no checking for jpeg_read_header in -ljpeg... yes checking for PKG_LIBQUICKTIME_CFLAGS... checking for PKG_LIBQUICKTIME_LIBS... checking for libquicktime-config... no checking for quicktime_init in -lquicktime... yes checking for PKG_LQT_CFLAGS... checking for PKG_LQT_LIBS... checking for lqt-config... yes checking for PKG_MPEG3_CFLAGS... checking for PKG_MPEG3_LIBS... checking for mpeg3-config... no checking for mpeg3_check_sig in -lmpeg3... yes checking for PKG_MPEG_CFLAGS... checking for PKG_MPEG_LIBS... checking for mpeg-config... no checking for OpenMPEG in -lmpeg... yes checking for PKG_AVIFILE_CFLAGS... -I/usr/include/avifile-0.7 checking for PKG_AVIFILE_LIBS... -laviplay checking for PKG_FFMPEG_CFLAGS... checking for PKG_FFMPEG_LIBS... checking for ffmpeg-config... no checking for av_open_input_file in -lavformat... no checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking linux/videodev.h usability... yes checking linux/videodev.h presence... yes checking for linux/videodev.h... yes checking for PKG_IEEE1394_CFLAGS... checking for PKG_IEEE1394_LIBS... checking for ieee1394-config... no checking for main in -ldv... yes checking for PKG_FTGL_CFLAGS... -I/usr/include/freetype2 checking for PKG_FTGL_LIBS... -lGLU -lGL -lfreetype -lz -lftgl checking for PKG_GLTT_CFLAGS... checking for PKG_GLTT_LIBS... checking for gltt-config... no checking for GLTTFont in -lgltt... no checking for pthread_create in -lpthread... yes checking for X... libraries /usr/X11R6/lib, headers in standard search path checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking for memory.h... (cached) yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking for unistd.h... (cached) yes checking for stdbool.h that conforms to C99... yes checking for _Bool... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking for GLsizeiptrARB... yes checking for unsigned int... yes checking size of unsigned int... 4 checking for void *... yes checking size of void *... 4 checking for error_at_line... yes checking for pid_t... yes checking for unistd.h... (cached) yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking whether gcc needs -traditional... no checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for bzero... yes checking for floor... yes checking for gettimeofday... yes checking for memset... yes checking for munmap... yes checking for pow... yes checking for sqrt... yes checking for strchr... yes checking for strdup... yes checking for strrchr... yes checking for strstr... yes checking for lqt_add_video_track... no checking for glBindProgramARB... yes checking for glBindProgramNV... yes checking m_pd.h usability... yes checking m_pd.h presence... yes checking for m_pd.h... yes checking whether compiler accepts "-freg-struct-return"... yes enabling "register struct return" allows to make use of FreeFrame-effects without recompiling them might break things, if you are using several different compilers checking whether compiler accepts "-O3"... yes checking whether compiler accepts "-fno-builtin"... yes checking whether compiler accepts "-falign-loops=16 -funroll-loops"... yes checking whether compiler accepts "-ffast-math"... yes checking whether compiler accepts "-mmmx"... yes checking whether compiler accepts "-faltivec"... no checking whether linker accepts "-shared -Wl,-export-dynamic"... yes checking whether linker accepts "-bundle -bundle_loader /usr/local/bin/pd"... no checking for strip... strip checking if strip is GNU strip... yes checking for dos2unix... true configure: creating ./config.status config.status: creating Make.config config.status: creating Base/configLinux.h config.status: Base/configLinux.h is unchanged

Result: Target : Gem.pd_linux Objects : Base Controls Geos Manips MarkEx Nongeos Particles Pixes openGL

Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -O3 -fno-builtin -falign-loops=16 -funroll-loops -ffast-math -mmmx : -I/usr/include/quicktime -I/usr/include/avifile-0.7 -I/usr/include/freetype2 INCLUDES : -I/usr/include/FTGL -I/usr/include/freetype2 DEFINES :

LIBS : -ldv -lmpeg -lmpeg3 -lquicktime -ljpeg -ltiff -lGLU -lGL -lXext -lXxf86vm -lXext -lX11 -ldl -lz -lm -L/usr/X11R6/lib -lpthread : -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.39

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 : no 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 ...

IOhannes m zmoelnig a écrit :

chris clepper wrote:

...

I put a build up that fixes the crash when QT load, has some of my more

fine.

...

recent pix_ objects and does ARB_ shaders. I also moved the QT init code into the GemMan init and added a fps output to gemwin (not checked into CVs

hmm, why don't we just use [realtime] in connection with a [gemhead]-trigger? this way we would not need to change anything in C - it is all there already (not that this is really a question and not even a suggestion...)

it would be great if you could check in your changes asap, esp. an updated project-file.

i would like to make a release whenever possible. any known open bugs, that are likely to be fixed within the next days?

the only bugs that come to my mind are:

• "external" window closing is likely to crash pd (linux)
• "destroy" sometimes hangs (cannot reproduce it, but i believe the

bug-report; i guess this is highly hw-dependent; linux)

• autoconf build-system on osX

-- certainly a lot of others which i have forgotten

i don't think that the window-crashes on linux are likely to be fixed before 0.91; i would like the osX-autoconf to work again, so if somebody could spare some time on that i would be thankful.

apart from that i would highly recommend a feature freeze right now.

what do you think?

mfg.asd.r IOhannes

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

hello,

chris clepper a écrit :

On 3/9/06, *cyrille henry* <cyrille.henry@la-kitchen.fr mailto:cyrille.henry@la-kitchen.fr> wrote:

hello,

this windows build is to late for me but a friend tested it on 2
differents computer (pd 38.2 + winXPpro sp2). gem does not load because
glew32.dll or MSVCP71.dll is missing.

The glew one is probably just an oversight in the build settings, but I don't know what would cause the need for the MSVC dll. Perhaps there is some sort of debug setting that triggers it?

i did not try myself, so i can't be sure, but i don't think my friend have any special settings...

exept that, my list of "bug" that could be fixed :

pix_write write images upside down in .jpg, but images are correct
in .tif 

Coordinate systems vary so TIFF might start from the bottom left like GL while JPG starts at the top right. Quicktime and DirectShow seem to be opposite from one another as well.

ok.

there was a discussion about making remanence effect with alpha for the
gemwin background. i noticed some change was made on the source code to
allow alpha in the background color, but i still not able to make it
work.

Sounds like something that would only work in single buffered mode without saving the buffer somewhere and compositing it back in. Using pix_snap2tex will do the second option.

ok. i'm using pix_snap2tex for now, i was just looking for something easier. but pix_snap2tex is more powerfull as it can be used on distorded surface...

thanks Cyrille

IOhannes m zmoelnig a écrit :

cyrille henry wrote:

...

hello,

for now : pix_record does not compile on my system. (and never did) (still using ubuntu breezy)

pix_record.cpp: In constructor ‘pix_record::pix_record(int, t_atom*)’: pix_record.cpp:55: erreur: cannot allocate an object of abstract type ‘recordQT4L’ ../Pixes/recordQT4L.h:38: note: because the following virtual functions are pure within ‘recordQT4L’: ../Pixes/record.h:73: note: virtual int record::putFrame(imageStruct*) make[1]: *** [pix_record.o] Erreur 1

thanks for that. it should be fixed now in CVS. for the impatient: change line54 to #elif defined HAVE_LIBQUICKTIME && defined HAVE_LQT_ADD_VIDEO_TRACK

it compile now. i will try it later. thanks

...

exept that, my list of "bug" that could be fixed :

pix_write write images upside down in .jpg, but images are correct in .tif

i assume you are _not_ using ImageMagick?

i'll have a look at it.

i should have imageMagick.

here is my ./confugure

cyrille@nusmuk:~/pd/Gem/src$ ./configure checking for Base/configLinux.h.in... yes checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for sin in -lm... yes checking for main in -lz... yes checking for dlopen in -ldl... yes checking how to run the C preprocessor... gcc -E checking for X... libraries /usr/X11R6/lib, headers in standard search path checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for main in -lX11... yes checking for main in -lXext... yes checking for XF86VidModeGetAllModeLines in -lXxf86vm... yes checking for main in -lXext... (cached) yes checking for glInitNames in -lGL... yes checking for gluLookAt in -lGLU... yes checking for "OpenGL"-framework... no checking for "AGL"-framework... no checking for "Carbon"-framework... no checking for "QuickTime"-framework... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for PKG_IMAGEMAGICK___CFLAGS... checking for PKG_IMAGEMAGICK___LIBS... -lMagick++ -lMagick checking for PKG_TIFF_CFLAGS... checking for PKG_TIFF_LIBS... checking for tiff-config... no checking for TIFFOpen in -ltiff... yes checking for PKG_JPEG_CFLAGS... checking for PKG_JPEG_LIBS... checking for jpeg-config... no checking for jpeg_read_header in -ljpeg... yes checking for PKG_LIBQUICKTIME_CFLAGS... checking for PKG_LIBQUICKTIME_LIBS... checking for libquicktime-config... no checking for quicktime_init in -lquicktime... yes checking for PKG_LQT_CFLAGS... checking for PKG_LQT_LIBS... checking for lqt-config... yes checking for PKG_MPEG3_CFLAGS... checking for PKG_MPEG3_LIBS... checking for mpeg3-config... no checking for mpeg3_check_sig in -lmpeg3... yes checking for PKG_MPEG_CFLAGS... checking for PKG_MPEG_LIBS... checking for mpeg-config... no checking for OpenMPEG in -lmpeg... yes checking for PKG_AVIFILE_CFLAGS... -I/usr/include/avifile-0.7 checking for PKG_AVIFILE_LIBS... -laviplay checking for PKG_FFMPEG_CFLAGS... checking for PKG_FFMPEG_LIBS... checking for ffmpeg-config... no checking for av_open_input_file in -lavformat... no checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking linux/videodev.h usability... yes checking linux/videodev.h presence... yes checking for linux/videodev.h... yes checking for PKG_IEEE1394_CFLAGS... checking for PKG_IEEE1394_LIBS... checking for ieee1394-config... no checking for main in -ldv... yes checking for PKG_FTGL_CFLAGS... -I/usr/include/freetype2 checking for PKG_FTGL_LIBS... -lGLU -lGL -lfreetype -lz -lftgl checking for PKG_GLTT_CFLAGS... checking for PKG_GLTT_LIBS... checking for gltt-config... no checking for GLTTFont in -lgltt... no checking for pthread_create in -lpthread... yes checking for X... libraries /usr/X11R6/lib, headers in standard search path checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking for memory.h... (cached) yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking for unistd.h... (cached) yes checking for stdbool.h that conforms to C99... yes checking for _Bool... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking for GLsizeiptrARB... yes checking for unsigned int... yes checking size of unsigned int... 4 checking for void *... yes checking size of void *... 4 checking for error_at_line... yes checking for pid_t... yes checking for unistd.h... (cached) yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking whether gcc needs -traditional... no checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for bzero... yes checking for floor... yes checking for gettimeofday... yes checking for memset... yes checking for munmap... yes checking for pow... yes checking for sqrt... yes checking for strchr... yes checking for strdup... yes checking for strrchr... yes checking for strstr... yes checking for lqt_add_video_track... no checking for glBindProgramARB... yes checking for glBindProgramNV... yes checking m_pd.h usability... yes checking m_pd.h presence... yes checking for m_pd.h... yes checking whether compiler accepts "-freg-struct-return"... yes enabling "register struct return" allows to make use of FreeFrame-effects without recompiling them might break things, if you are using several different compilers checking whether compiler accepts "-O3"... yes checking whether compiler accepts "-fno-builtin"... yes checking whether compiler accepts "-falign-loops=16 -funroll-loops"... yes checking whether compiler accepts "-ffast-math"... yes checking whether compiler accepts "-mmmx"... yes checking whether compiler accepts "-faltivec"... no checking whether linker accepts "-shared -Wl,-export-dynamic"... yes checking whether linker accepts "-bundle -bundle_loader /usr/local/bin/pd"... nochecking for strip... strip checking if strip is GNU strip... yes checking for dos2unix... true configure: creating ./config.status config.status: creating Make.config config.status: creating Base/configLinux.h config.status: Base/configLinux.h is unchanged

Result: Target : Gem.pd_linux Objects : Base Controls Geos Manips MarkEx Nongeos Particles Pixes openGL

Configuration: Compiler : g++ CXXFLAGS : -g -O2 -freg-struct-return -O3 -fno-builtin -falign-loops=16 -funroll-loops -ffast-math -mmmx : -I/usr/include/quicktime -I/usr/include/avifile-0.7 -I/usr/include/freetype2 INCLUDES : -I/usr/include/FTGL -I/usr/include/freetype2 DEFINES :

LIBS : -ldv -lmpeg -lmpeg3 -lquicktime -ljpeg -ltiff -lGLU -lGL -lXext -lXxf86vm -lXext -lX11 -ldl -lz -lm -L/usr/X11R6/lib -lpthread : -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.39

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 : no 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 ...

thanks Cyrille

mf.adsr. IOhannes

cyrille henry wrote:

...

...

thanks for that. it should be fixed now in CVS. for the impatient: change line54 to #elif defined HAVE_LIBQUICKTIME && defined HAVE_LQT_ADD_VIDEO_TRACK

it compile now. i will try it later. thanks

ok. when i load a pix_record object, i've got the message : [pix_record]: Gem has been compiled without pix-recording capabilities!

so the question is : what should i do to compil gem with pix_recording capability?

recordQT4L uses a rather new API of libquicktime (which, btw, is not compatible with quicktime4linux any more); so you need a recent version of libquicktime (on my debian machine i have 0.9.7)

so the answer is basically: use an uptodate distribution like debian and not something old and rotten like ubuntu :-) (funny world this is)

i don't know how ubuntu is upgraded, but you could bother the maintainers for getting a newer version of libquicktime in the next release.

mfg.asdr. IOhannes

I would very much like this separator for texture coords thing fixed. Either I get a memory leak or I have to remove separator and try and figure out whats going on.

I use a lot of subchains with different textures...

I've had trouble making a test patch since the issue seems to only come up with a complex patch..

I'll try harder.

I've been pretty happy with the stability of the gem CVS stuff since I got it to compile thanks to Johannes. I can run a patch for a couple days (7300*12s at the moment)

.b.

IOhannes m zmoelnig wrote:

chris clepper wrote:

...

I put a build up that fixes the crash when QT load, has some of my more

fine.

...

recent pix_ objects and does ARB_ shaders. I also moved the QT init code into the GemMan init and added a fps output to gemwin (not checked into CVs

hmm, why don't we just use [realtime] in connection with a [gemhead]-trigger? this way we would not need to change anything in C - it is all there already (not that this is really a question and not even a suggestion...)

it would be great if you could check in your changes asap, esp. an updated project-file.

i would like to make a release whenever possible. any known open bugs, that are likely to be fixed within the next days?

the only bugs that come to my mind are:

• "external" window closing is likely to crash pd (linux)
• "destroy" sometimes hangs (cannot reproduce it, but i believe the

bug-report; i guess this is highly hw-dependent; linux)

• autoconf build-system on osX

-- certainly a lot of others which i have forgotten

i don't think that the window-crashes on linux are likely to be fixed before 0.91; i would like the osX-autoconf to work again, so if somebody could spare some time on that i would be thankful.

apart from that i would highly recommend a feature freeze right now.

what do you think?

mfg.asd.r IOhannes

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

On 3/9/06, B. Bogart ben@ekran.org wrote:

I would very much like this separator for texture coords thing fixed. Either I get a memory leak or I have to remove separator and try and figure out whats going on.

The texture coordinates have to be created before other objects can modify them. pix_texture has to be first in the chain ahead of separator and pix_coordinate. I use separator with switching the gem chains around and avoid the leak. We could perhaps fix the number of texture coordinates to four and have the gemhead create them and never destroy them until the gemhead destructor.

On 3/9/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:

hmm, why don't we just use [realtime] in connection with a [gemhead]-trigger? this way we would not need to change anything in C - it is all there already (not that this is really a question and not even a suggestion...)

Timing bangs has never been accurate or reliable for me. SInce the profiling code was already there in GemMan, all I did was divide the result by 1000 to get fps and send that to an outlet.

it would be great if you could check in your changes asap, esp. an

updated project-file.

I'm using vs.net so it will be a new project incompatible with the current vc6 one. I need to make sure it actually builds something usable on lots of machines too.

On 3/9/06, IOhannes m zmoelnig zmoelnig@iem.at wrote:

chris clepper wrote:

...

On 3/9/06, *IOhannes m zmoelnig* <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:

hmm, why don't we just use [realtime] in connection with a
[gemhead]-trigger? this way we would not need to change anything in

C -

...

it is all there already (not that this is really a question and not

even

...

a suggestion...)

Timing bangs has never been accurate or reliable for me. SInce the profiling code was already there in GemMan, all I did was divide the result by 1000 to get fps and send that to an outlet.

iirc, it has been there on osX for quite a long time (is that true?); so it's better to have it on all platforms than only on one.

I did it on the Mac because the bang timing was so bad. Windows is not quite that bad but it is inaccurate. I did not dod the linux part because I have no way to test it currently.

i think it should be possible to have vc6 and vs.net files

simultaneously, just make sure the project files have different names.

I used the VC6 project to make the new one so it has the same name, but it is a separate file in the Win filesystem. I don't really know which files are needed for the session and what can be renamed safely. Should I maybe zip the files up?

builds something usable on lots of machines too.

the simplest way to make that sure would be, to submit it, so that lots of people can try it on their machines.

I have put a new build up at http://taproot.dyndns.org/~cgc/downloads/Gem.dll

This loads and runs on a machine here without glew or msvc installed.

cgc

Zitat von IOhannes m zmoelnig zmoelnig@iem.at:

...

I have put a new build up at http://taproot.dyndns.org/~cgc/downloads/Gem.dll

This loads and runs on a machine here without glew or msvc installed.

i have checked it on my girlfriends machine (w2k) and it complained about a missing MSVCP71.dll. a bit of googling lead me to http://download.overnet.org/msvcp71.dll where i downloaded it (put it into %SYSTEM32%) and it loaded fine (haven't done any tests yet)

so i've started a bit of testing, and it seems to run fine. however, i noticed that several objects are missing in this build. while some of them are very new, at least [pix_sig2pix~] is rather old (and i guess they are already in the 0.90 release - no way to test _this_ though)

This is the list of missing objects (i haven't tested the openGL-wrapper yet) gemframebuffer gemtablet GemSplash pqtorusknots glsl_fragment glsl_program glsl_vertex part_sink pix_fiducialtrack pix_hit pix_multitexture pix_sig2pix~ pix_threshold_bernsen pix_vpaint

of course they ought to be added before any release

mfg.asdr. IOhannes

cyrille henry wrote:

en bugs, that are likely to be fixed within the next days?

i just found that pd crash when i try to load bad file with pix_image, after loading a valid file.

"bad files" mean : files that does not exist files that are not jpeg or tiff

(linux)

i cannot reproduce this on my machine. i just get "/tmp/foo.jpg: not found" and the like.

which libs is Gem using for image decompression? which versions? do you have magick++-support?

it is ubuntu-breezy(?), but which hardware (i686, x86_64, ppc?)

could you do a backtrace?

mfg.a.dsr IOhannes

cyrille henry wrote:

i just found that pd crash when i try to load bad file with pix_image, after loading a valid file.

"bad files" mean : files that does not exist files that are not jpeg or tiff

i just got the same behaviour with the most recent libstdc++: raising exceptions results in a crash! (which is normal if you don't catch the exception; however with certain combinations of compiler++/libstdc++ it also crashes when the exception ought to be caught)

now the ImageMagick code does throw an exception when the image-loading fails, but it is usually caught. so this might explain what happened to you.

this is all related to my recent upgrade to debian/sid; (the crashes occur when libstdc++6-4.1.0-1+b1 is installed but not with libstdc++6-4.0.2-9)

other objects involved are e.g. [pix_freeframe] when no (valid) freeframe-plugin is given as argument.

mfg.asd.r IOhannes

On Mar 10, 2006, at 10:28 AM, james tittle wrote:

On Mar 9, 2006, at 4:33 AM, IOhannes m zmoelnig wrote:

...

i would like to make a release whenever possible. any known open bugs, that are likely to be fixed within the next days?

the only bugs that come to my mind are:

• "external" window closing is likely to crash pd (linux)
• "destroy" sometimes hangs (cannot reproduce it, but i believe the

bug-report; i guess this is highly hw-dependent; linux)

• autoconf build-system on osX

-- certainly a lot of others which i have forgotten

i don't think that the window-crashes on linux are likely to be fixed before 0.91; i would like the osX-autoconf to work again, so if somebody could spare some time on that i would be thankful.

...yep, I'll be working on that, but likely not until next tuesday...sorry I let this go, but I'm just too used to working in a gui IDE...and I'm way overdue on updating the xcode project files...

...

apart from that i would highly recommend a feature freeze right now.

what do you think?

...sounds good to me...here's what I'm working on for a release:

• helpfiles for glsl_*, and making sure the others are current
• making [rubber] infinitely more interesting (almost done!)
• remove the osx checks for valid gl contexts, since we now have a

"masterContext" created on startup

• I'd really like to finish alitivec'ing yuv to rgb/a and rgb/a to yuv

...anyone wanna make analogs of these in mmx/sse2/sse3?

• make [pix_multitexture] a bit more usable
• [env $1< to [pix_texture] also takes symbol names (ie. blend,

modulate, etc.)

• compare speeds of CACHED vs. SHARED texture hints, particularly

with regard to gpu shader interaction (CACHED is supposed to remove a copy to VRAM which speeds up texture lookups in shaders, but does it have any slowdown otherwise?)

...and then there are the bugs, or things that don't work as they should, like the recent stencil buffer stuff...

...just thought of a coupla other things on my soon-to-do:

- add switch colorspaces to [gemframebuffer]: float, rgb, rgba? - make [gempbuffer], which more drivers support better than FBO's (still!)?

...anything else?

jamie

chris clepper wrote:

On 3/11/06, *james tittle* <tigital@mac.com mailto:tigital@mac.com> wrote:

...anything else?

There is a very serious long term stability bug in the OSX SequenceGrabber code. It could take weeks to find and fix it.

has this already been in the 0.90 release? if so, i guess we can just live withit for another release-cycle...

mfg.adsr IOhannes

chris clepper wrote:

On 3/12/06, *IOhannes m zmölnig* <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:

chris clepper wrote:
 > There is a very serious long term stability bug in the OSX
 > SequenceGrabber code.  It could take weeks to find and fix it.
 >

has this already been in the 0.90 release?
if so, i guess we can just live withit for another release-cycle... 

It's new and we cannot just live with it.

i agree. i already thought that i must be new, since i couldn't really imagine how you would do your very-long term installations with this bug...

too bad. when has it bee introduced?

mf.asdr. IOhannes

chris clepper wrote:

On 3/12/06, *IOhannes m zmölnig* <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:

chris clepper wrote:
> There is a very serious long term stability bug in the OSX
> SequenceGrabber code.  It could take weeks to find and fix it.
>

has this already been in the 0.90 release?
if so, i guess we can just live withit for another release-cycle... 

It's new and we cannot just live with it.

another idea: would it be an option if we did the release asap (even without this fix!) and do a 0.91.1 bugfix-release as soon as it has been found and fixed?

apart from that, what is needed to produce the instability? just hook a camera to my G4, turn grabbing/rendering on and wait?

mfg.adr IOhannes

chris clepper wrote:

On 3/19/06, *IOhannes m zmoelnig* <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:

another idea: would it be an option if we did the release asap (even
without this fix!) and do a 0.91.1 bugfix-release as soon as it has been
found and fixed?

apart from that, what is needed to produce the instability? just hook a
camera to my G4, turn grabbing/rendering on and wait?

The bug so far only happens on dual g5, but if you have a dual g4 it might be interesting to test. It's still not clear what the cause is, but multiple capture devices, especially if one is a DV device, seem to be the trigger. I haven't tested 10.3 and Quicktime 6.5 either since neither of those are an option for me anymore, but that info could be

ok, i will try to have a look at our dual g4 (running 10.3 iirc, no idea about the quicktime-version); the only capturing device i have might be a dv-camera, well probably i can find some usb-webcam that might work under osx.

I don't like the idea of a version with a known flaw to be widely circulated even if most people won't likely encounter it. It just creates confusion and problems.

and of course my hurry about the release is probably exaggerated; however i'd like to get it running asap.

The Windows version still needs a lot of help prior to release as well. I don't even know if I'm building a binary that most people can even load!

still my tests have not gone beyond loading Gem on a vanilla w2k with all recent service-packs installed (i posted the result already: the msvc70.dll was needed (i think it comes already with xp), but after i installed that one Gem loaded fine)

should we try to retain binary compatibility with w32 version prior to 2k? like w98?? i don't think so.

i would dearly beg you to find a way how to submit the vs.net project files (preferrably without interfering with other files: maybe it is possible to just put it into a separate directory)

mfg.asdr. IOhannes

hey chris,

On Mar 19, 2006, at 2:58 PM, chris clepper wrote:

The bug so far only happens on dual g5, but if you have a dual g4 it might be interesting to test. It's still not clear what the cause is, but multiple capture devices, especially if one is a DV device, seem to be the trigger. I haven't tested 10.3 and Quicktime 6.5 either since neither of those are an option for me anymore, but that info could be useful as well. I will probably be working with Apple on tracking down the issue soon, so hopefully they can provide some (paid) help.

...I don't know if this has been solved, but while thinking and poking around regarding erich's more recent question about resource reclamation in film loading, I started looking into "setgworld()", which we don't use in film-handling (we do use SetMovieGWorld(), but is that enough by itself?), but we do use in pix_video (ie. SGSetGWorld())...I bring this up because I stumbled across this old post from milton aupperle on quicktime-api (june 27, 2003):

Also, under OS 9/pre carbon , something like

SGSetGWorld(gSGInfo.theSG, (CGrafPtr)gCaptureWindow, NULL);

worked fine, but under Carbon, you can no longer just type cast the port into the correct type, you have to specifically use the correct selector type such as

SGSetGWorld(gSGInfo.theSG, GetWindowPort(gCaptureWindow), NULL);

to extract the correct CGrafPtr. Otherwise "interesting" things happened.

...we are currently using the "bad" casting method, so maybe switching to the accessor will keep your "interesting" things from occurring? Long shot, but then we are clawing at air...

jamie

On Mar 14, 2006, at 10:40 AM, IOhannes m zmoelnig wrote:

james tittle wrote:

...

• helpfiles for glsl_*, and making sure the others are current

i've added reference patches for all shader-objects.

...beat me to it ;-) I'll check 'em out...

...

• making [rubber] infinitely more interesting (almost done!)
• remove the osx checks for valid gl contexts, since we now have a

"masterContext" created on startup

so can i just go on and remove all occurences (in the "real" object-files) of these context-tests?

...um, I think it'd be a bit better for me to go ahead and do this, because it'd be easier for me to find out if it works or not :-) I'll start on that now...

jamie

james tittle wrote:

On Mar 14, 2006, at 12:03 PM, james tittle wrote:

...ok, I just made a bunch of commits regarding this, in addition to many things I committed this morning, and still haven't received any notification on the GEM-cvs list: is it down?

the GEM-cvs list is hosted by sourceforge (one of the very few pd-related mailing lists i am subscribed to which is not hosted by the iem) - and as everything on sourceforge, it might have problems now and then due to overload (on other services).

anyhow, i received a lot of mails from imageVert to pix_multitexture.

mfg.asdr. IOhannes