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 …
[View More]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
[View Less]
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
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
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 …
[View More]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
[View Less]
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
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.
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 …
[View More]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
[View Less]
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?
(…
[View More]would be cool to fix this problem)
thanks
cyrille
class dummyTabletKill
{
public:
~dummyTabletKill();
};
dummyTabletKill:: ~dummyTabletKill()
{
if (s_winTabLib)
{
// WTClosePtr(TabletContext);
FreeLibrary(s_winTabLib);
}
}
[View Less]
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 …
[View More]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
[View Less]
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 ..…
[View More]/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
[View Less]