GEM-dev December 2003

gem-dev@lists.iem.at

9 participants
20 discussions

release date
by chris clepper 25 Mar '04

25 Mar '04

So we keep talking and talking about a release of 0.888, and I think maybe just setting a date and sticking to it will actually make it happen. I propose two weeks from today December the 2nd to be that date. There's no reason it couldn't be done by next week, but two gives a bit more time for the loose ends. The critical thing I see right now is making sure there is as much documentation in the release as possible. At the very least, every object should have a help file that lists all of the (working) features of the object. Here's a list of objects I don't have help for: - curve3d - camera - pix_dv I can also add my beginner tutorial to CVS, although it does contain images which would add a few hundred KB to the distribution. Bug fixes/enhancements: - pix_biquad does next to nothing now. The coefficients seem to determine how fast the image fades to black. I reverted two versions and it worked as it always has. Any ideas what's going on? - pix_write gave me some serious trouble last night. if i didn't give it a 'file ' message it overwrote the pd binary!! that's some really bad news, and i've gone through 3 versions of pd in the last 24 hours. i'm not sure what's going on but the default setup no longer writes 'gem000x.tif' in pd/bin for some reason. - i mixed up versions of pix_filmDarwin/YUV and need to get them sorted out. - i will probably add some more Altivec code. We need to decide where the binary distributions will reside. Sourceforge project page? IEM? Both? Somewhere else? Someone needs to build a version for OSX and a version for Windows by this weekend so we can check them on a few machines and be somewhat sure nothing is terribly wrong with them. A few changes and tweaks will probably be needed but there should be enough time to do them. I think we should also plan on another point release by the beginning of next year to address problems with 0.888 (will it be 0.889 or 0.89?). Assuming we don't horribly fuck up 0.888 there won't be a huge rush for these fixes. I really want to put an end to getting bug reports on versions that are years out of date or come from some unknown origin. Further down the road, 0.90 could be a major release incorporating large changes and additions like my vertex-array objects and shader support. I cannot reasonably estimate a time frame for that, although I am working towards making significant progress on the vertex stuff by year's end, and will commit code to CVS by then. That's all I can think of right now. cgc

8 21

more new primitive for gem...
by Cyrille Henry 25 Mar '04

25 Mar '04

hello, I made a new primitive for gem : curve3D.... juste like curve, but in 3D! you may find stuff here : http://drpichon.free.fr/pure-data/GEM/curve3D/ picts, source, exemple and gem.dll for windows user... hope you'll like it... Cyrille

4 6

altivec on linux/PPC
by B. Bogart 25 Mar '04

25 Mar '04

Hey all, I just had the idea that it would be nice if linux/Gem for PPC used the same altivec acceleration as the OSX version. How hard would it be to put this in the build system? Just thinking out loud... Ben

2 1

Re: Gem/src/Pixes pix_filmDarwin.cpp,1.18,1.18
by IOhannes zmoelnig 25 Mar '04

25 Mar '04

cclepper(a)users.sourceforge.net wrote: > Update of /cvsroot/pd-gem/Gem/src/Pixes > In directory sc8-pr-cvs1:/tmp/cvs-serv9968 > > Modified Files: > pix_filmDarwin.cpp > Log Message: > rewrite to make playback using 'auto' more efficient. 'rate' message sets the playback speed when using 'auto' mode. > the movie rate is properly set for correct qt playback. hi. i have already implemented something similar under linux, but of course, differently. i am simply using the argument to "auto" as the framerate. so with "auto 0", no auto-playback is used, with "auto 1", we have normal speed playback. with "auto 0.5", we have half-speed playback. is this confusing to the user ? mfg.as.dr IOhannes

7 8

curve width
by B. Bogart 25 Mar '04

25 Mar '04

Hey all, It seems that lines (at least for curve, probably others) are limited to 10pixels thick. Is this a Gem or openGL limitation? It would be nice to have curves as thick as 300pixels or more... :) Thanks Ben

2 1

pix_downsample
by B. Bogart 21 Dec '03

21 Dec '03

Hey All, Is there an object (or plans for) a pix_ object that drops the resolution of a pix_stream to a specified resolution? I think it would be great for tracking stuff by using pix_movement a live camera and then using the downsampled images as a region grid. With few pixels you could read the "movement" in each region using pix_data (a little hard to use at high-resolution) B.

1 0

Re: [PD] pix_background - no method for blur
by IOhannes zmoelnig 19 Dec '03

19 Dec '03

robcanning wrote: > hi > i think there is definitely something wrong with that right inlet in > pix_background > its not just me who has encountered the pix_background: no method for > 'blur' error on windows. > the left inlet works fine. > perhaps the help file should be modified to show how the range $1 $2 $3 > message can be passed to the left inlet. > i still haven't tried it under windows (sorry), but it works under linux. did you compile it yourself or is did you get a ready-made binary somewhere (where?) i am not sure about documenting the 1st inlet. i still think that it is confusing to have several ranges for colors (0to255 vs 0.0to1.0). [but i agree, that objects refusing to work are even more confusing] since Gem's openGL-colors (like [colorRGB]) are float-values (0.0to1.0) for ages, i favour these one. now for [pix_tIIR] which version are you using ? compiled yourself ? it is there on my machine... mfg.a.sdr IOhannes

1 0

gem tablet problem
by Cyrille Henry 17 Dec '03

17 Dec '03

hello, I try to search why GEM output error each time I close pd since I installed a graphic tablet. I remove the line : WTClosePtr(TabletContext); in the dummyTabletKill fonction. (line 204 of the curent CVS version) I don't really knows what this line sould do, but removing it solve my problem, I have no more error messages. The tablet still works correctly, with gemtablet or on windows etc. I use this for few days and I did'nt notice anything special... can someone else test this? (would be cool to fix this problem) thanks cyrille class dummyTabletKill { public: ~dummyTabletKill(); }; dummyTabletKill:: ~dummyTabletKill() { if (s_winTabLib) { // WTClosePtr(TabletContext); FreeLibrary(s_winTabLib); } }

1 0

Re: FFMPEG in GEM
by IOhannes zmoelnig 08 Dec '03

08 Dec '03

Henning Haaland Kulander wrote: > On Wed, 3 Dec 2003, IOhannes zmoelnig wrote: > > > I have tried setting m_image.image.upsidedown to 1 and 0, but there is no > change. Still upsidedown. i tried it too. it worked for me. >>the other problem is BGR-colorspace (or BGRA) vs RGB(A). >>(pix_* processing in) Gem supports 3 different colorspaces: GL_RGBA, >>yuv422 (UYVY) and Greyscale (GL_LUMINANCE). the [pix_texture] just >>passes the current-colorspace to the renderer, thus supporting other >>formats like GL_BGR too. > > > I don't get this either. The ffmpeg streams I've tried are YUV420, and the > ressult should be GL_RGBA. The plugins tries to use img_convert with the > correct colorspaces as paramters, but the output is still wrong. I haven't > tried the fromBGR hack yet. It seems wrong to first convert from YUV to > BGR and then from BGR to RGB... this turned out to be a bit complicated PIX_FMT_RGBA32 is not RGBA (as i would have thought) but it is really BGRA (on intel and friends: little_endian) and ARGB (on big-endians) and although it seems wrong to do too much conversion, it is the easiest for now. Gem supports a lot of conversion-routines by itself, so we could use these (but this needs time, as to find out what ffmpeg means with it's formats (like RGBA32 beeing anything but RGBA (in this order)) the attached files make this double conversion for convenience. i am afraid, these changes will not make it into the next release. mfg.as.dr IOhannes

4 3

FTGL only making static libs?? :(
by ben＠ekran.org 06 Dec '03

06 Dec '03

Hello all, and Henry. I'm trying to get FTGL to work from source. It will not compile becuase it is trying to compile a static library, and is trying to link to libGL.la (which does not exist on my system). Now Does gem care if FTGL is static or shared? I have configured FTGL with: ./configure --enable-shared --disable-static But still FTGL will try and link a libftgl.la. The target in FTGL/unix/src/Makefile is indeed libftgl.la Here is the compile error (libGL.la not existing) /bin/sh ../libtool --mode=link g++ -o libftgl.la -rpath /usr/local/lib FTBitmapGlyph.lo FTCharmap.lo FTContour.lo FTExtrdGlyph.lo FTFace.lo FTFont.lo FTGLBitmapFont.lo FTGLExtrdFont.lo FTGLOutlineFont.lo FTGLPixmapFont.lo FTGLPolygonFont.lo FTGLTextureFont.lo FTGlyph.lo FTGlyphContainer.lo FTLibrary.lo FTOutlineGlyph.lo FTPixmapGlyph.lo FTPoint.lo FTPolyGlyph.lo FTSize.lo FTTextureGlyph.lo FTVectoriser.lo -lfreetype -lz -lGLU -lGL grep: /usr/lib/libGL.la: No such file or directory /usr/bin/sed: can't read /usr/lib/libGL.la: No such file or directory libtool: link: `/usr/lib/libGL.la' is not a valid libtool archive make[1]: *** [libftgl.la] Error 1 Does FTGL *have* to be static? Does Gem require static or shared? SUSE was great, it had all the upto date stuff, now my 8.0 is dated and I have to upgrade to get new packages... blech. Now that I actually have a lot of stuff in my linux system is when I need to change/ungrade the damn thing. :( Thanks Ben

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev December 2003