GEM-dev May 2008

gem-dev@lists.iem.at

14 participants
25 discussions

gem-0.91.0
by IOhannes m zmölnig 12 Jun '08

12 Jun '08

i have bundled whatever there is in current in the current v0-91 branch and put the files online: http://gem.iem.at/releases/0.91.0 like always, this is full of bugs. the one that is bothering me most at the time is RGBA on osx. the entire codebase is full of inconsistencies regarding the byte-order on big- and litte-endian machines. i think that fixing these will take a long time and a lot of code changes and i am not sure whether we should delay a release any longer. i will hopefully be working on this (at least, if chris isn't faster;-)) in the next weeks and eventually release 0.91.1 as a bugfix release. if you agree i will announce the release on the pd-announce. mfgads.r IOhannes

2 1

framebuffer and pix_data
by cyrille henry 01 Jun '08

01 Jun '08

hello, i would like to access color data of a framebuffer. just like pix_data, but working with a framebuffer. i'm specially interested with framebuffer because i need to have more than 8 bit/color (i'd like to use RGB32 format). pix_write use successfully the frambuffer, but i can't make pix_snap to work. is there a solution, and if not, what would be the best to do in order to make this possible? thx cyrille

4 11

RGBA confusion...
by IOhannes m zmoelnig 01 Jun '08

01 Jun '08

as hinted in my last email, Gem seems to have different hardcoded ideas about what RGBA means (esp. on OSX) the main confusion is about which "type" to use: GL_UNSIGNED_INT_8_8_8_8_REV vs GL_UNSIGNED_INT_8_8_8_8 the solution seems to be simple (_REV on ppc, normal on i686) but it seems to be done inconsistently in the source code, thus resulting in all the alpha problems marius has reported. i have created a wiki-page that tries to explain the technical implementation of Gem's standard colorspaces, which can be found at http://gem.iem.at/documentation/GemWiki/ColorSpace i have filled this page to my best knowledge, but i would be glad if somebody who knows what they are doing could have a look at it and confirm (or correct) everything (esp. those lines marked with "?") fgmasdr IOhannes

6 15

Re: [GEM-dev] Pix_write question
by chris clepper 28 May '08

28 May '08

The gemwin needs to be sized 1920 by 1080 too.. On Wed, May 28, 2008 at 1:40 PM, Studio Zodiak <studiozodiak(a)yahoo.ca> wrote: > I must be doing something wrong then. > I can capture the images fine, it's just that the whole image is only > rendered on 2/3 of the final output. > See attachement. > I have a message sending 1920 1080 to the second output of the pix_write > object. > > Sylvain > > > ----- Original Message ---- > From: chris clepper <cgclepper(a)gmail.com> > To: Studio Zodiak <studiozodiak(a)yahoo.ca> > Cc: gem-dev <gem-dev(a)iem.at> > Sent: Wednesday, May 28, 2008 2:31:01 PM > Subject: Re: [GEM-dev] Pix_write question > > I have captured images up to 3840 pixels wide on OSX. The limitation for a > single window on most platforms is 4096x4096 and I'm not aware of any > limitations in codecs or APIs related to compressing or handling an image > file. > > Have you had problems capturing a large image? > > On Wed, May 28, 2008 at 1:16 PM, Studio Zodiak <studiozodiak(a)yahoo.ca> > wrote: > >> Hi all. >> Is there a maximum size of frames i can write with Pix_write? >> >> Thx >> >> ------------------------------ >> Be smarter than spam. See how smart SpamGuard is at giving junk email the >> boot with the *All-new Yahoo! Mail *<http://ca.promos.yahoo.com/newmail/overview2/> >> >> _______________________________________________ >> GEM-dev mailing list >> GEM-dev(a)iem.at >> http://lists.puredata.info/listinfo/gem-dev >> >> > > ------------------------------ > Be smarter than spam. See how smart SpamGuard is at giving junk email the > boot with the *All-new Yahoo! Mail *<http://ca.promos.yahoo.com/newmail/overview2/> >

1 0

Re: [GEM-dev] Pix_write question
by Studio Zodiak 28 May '08

28 May '08

I am sorry for sending an 2MB attchement to the mailing list, I hope that wasn't a problem for anyone S ----- Original Message ---- From: chris clepper <cgclepper(a)gmail.com> To: Studio Zodiak <studiozodiak(a)yahoo.ca> Cc: gem-dev <gem-dev(a)iem.at> Sent: Wednesday, May 28, 2008 2:31:01 PM Subject: Re: [GEM-dev] Pix_write question I have captured images up to 3840 pixels wide on OSX. The limitation for a single window on most platforms is 4096x4096 and I'm not aware of any limitations in codecs or APIs related to compressing or handling an image file. Have you had problems capturing a large image? On Wed, May 28, 2008 at 1:16 PM, Studio Zodiak <studiozodiak(a)yahoo.ca> wrote: Hi all. Is there a maximum size of frames i can write with Pix_write? Thx ________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail _______________________________________________ GEM-dev mailing list GEM-dev(a)iem.at http://lists.puredata.info/listinfo/gem-dev __________________________________________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca

1 0

Pix_write question
by Studio Zodiak 28 May '08

28 May '08

Hi all. Is there a maximum size of frames i can write with Pix_write? Thx __________________________________________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca

2 1

pix _snap and pix_data
by cyrille henry 28 May '08

28 May '08

hello, i can't make pix_data to work with pix_snap. is there a problem with my patch? thanks Cyrille #N canvas 741 93 444 655 10; #X obj 40 32 gemhead; #X floatatom 77 351 4 0 0 1 width - -; #X floatatom 88 333 4 0 0 1 height - -; #X floatatom 99 315 4 0 0 1 bytes/pixel - -; #X floatatom 109 298 5 0 0 1 coulorspace - -; #X obj 67 277 pix_info ----; #X msg 40 179 snap; #X obj 40 55 t b a; #X obj 67 136 pix_texture; #X obj 67 116 pix_image; #X obj 52 397 pix_data; #X floatatom 82 377 5 0 0 0 - - -; #X floatatom 120 378 5 0 0 0 - - -; #X obj -2 368 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 74 420 unpack f f f; #X floatatom 74 443 5 0 0 0 - - -; #X floatatom 108 443 5 0 0 0 - - -; #X floatatom 143 443 5 0 0 0 - - -; #X obj 67 252 pix_write; #X obj 42 215 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj -103 78 gemwin; #X msg -97 53 0 \, destroy; #X obj 79 73 openpanel; #X obj 79 55 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 102 55 <-------------------- 1; #X text -70 216 2: OK ------->; #X text -85 368 3 : ------->; #X msg 79 92 open \$1; #X msg -103 32 create \, 1; #X obj 67 224 pix_snap; #X obj 67 156 sphere 4 33; #X connect 0 0 7 0; #X connect 5 0 10 1; #X connect 5 1 1 0; #X connect 5 2 2 0; #X connect 5 3 3 0; #X connect 5 4 4 0; #X connect 6 0 29 0; #X connect 7 0 6 0; #X connect 7 1 9 0; #X connect 8 0 30 0; #X connect 9 0 8 0; #X connect 10 1 14 0; #X connect 11 0 10 2; #X connect 12 0 10 3; #X connect 13 0 10 0; #X connect 14 0 15 0; #X connect 14 1 16 0; #X connect 14 2 17 0; #X connect 18 0 5 0; #X connect 19 0 18 0; #X connect 21 0 20 0; #X connect 22 0 27 0; #X connect 23 0 22 0; #X connect 27 0 9 0; #X connect 28 0 20 0; #X connect 29 0 18 0; #X connect 30 0 29 0;

2 4

particle system : bug ?
by pierre 27 May '08

27 May '08

Hello all, I use pd+gem a lot for doing audio/visual live show Thanks to all developers to keep it amazing Yesterday i was trying particles system and experienced a 'bug' with the patch /Gem/06.particles/07.render.pd pd crashes when i try to increase particles with [part_source], and/or by increasing [part_killold] im using Pd version 0.40-3extended-20080127, compiled 01:40:32 Jan 27 2008, under ubuntu feisty with nvidia proprietary drivers is it a bug in GEM or elsewhere (pd-extended nightlybuild...) ? and another question : which is the right way to report a bug ? (howto?) is this list appropriate ? Logs : ---------------------------------------------------------------------------------------------------------------------------------------- PD console : GL : stack underflow (never seen this before!?) ---------------------------------------------------------------------------------------------------------------------------------------- GDB output : rep@sushiboook:~$ gdb pd GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) run Starting program: /usr/local/bin/pd [Thread debugging using libthread_db enabled] [New Thread -1211763008 (LWP 13251)] tk scaling is 1.6821192053 [New Thread -1240523888 (LWP 13257)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211763008 (LWP 13251)] 0x080a9779 in pd_typedmess (x=0x82acc18, s=0x823a0c8, argc=2, argv=0xbfeccf30) at m_class.c:691 691 m_class.c: No such file or directory. in m_class.c ---------------------------------------------------------------------------------------------------------------------------------------- thanks, pierre

3 2

frambuffer does change the scene perspective
by cyrille henry 26 May '08

26 May '08

hello, when using a framebuffer in a patch, the perspective of the main windows is change to (-1, 1) in X and Y. So it's no more possible to use custom perspective (sending the perspec message to gemwin is useless). moreover, the perspective used lead to distorted images when the gemwin is not square. fixing this is quite easy, but will break all patch using frambuffer with a not square gem windows. so, i'm wondering if i should commit the fix. the fix is mainly to replace line 145 of gemframebuffer.cpp : glFrustum(-1,1,-1,1,1,25); with : float xDivy = (float)GemMan::m_w / (float)GemMan::m_h; glFrustum(GemMan::m_perspect[0] * xDivy, GemMan::m_perspect[1] * xDivy, // left, right GemMan::m_perspect[2], GemMan::m_perspect[3], // bottom, top GemMan::m_perspect[4], GemMan::m_perspect[5]); // front, back but it need to add #include "Base/GemMan.h" and to move static int m_w; static int m_h; from private to public in GemMan.h should i commit this? cyrille

5 12

problem with [pix_mask]
by Jack 25 May '08

25 May '08

Hello, I have a problem with the [pix_mask] object. The mask doesn't work. Before with pd-extended 0.39.3 and pd-extended 0.40.3 20080315, all works fine. I'm on PowerBook G4, MacOSX and pd-extended 0.40.3 20080520. Any idea ? Thanx. ++ Jack

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev May 2008