GEM-dev March 2004

gem-dev@lists.iem.at

6 participants
21 discussions

problem with curve on osX
by cyrille henry 25 Mar '04

25 Mar '04

hello, I've noticed a small problem on osX version of Gem. the problem is related with curve object. sometimes, curve objects are not drown properly. they can be drown with a random width, and can sometimes disepear. the problem is random, but it never happend the first time pd open a gemwindow. exemples : open pd + attached tst-curve. create gemwindow. ok, everyting is fine. close the patch. open the patch again. now, you should have some problem. (I've got problem with the 3 diferents computers on OSX (10.3) I tried). I tried diferents gem version. does anybody kown what to do? I rebember that I have the same problem long time ago on windows and linux, but the problem is gone... anyway, what's appening with "width" message to primitive. most, but not every, primitives accept a "width" messages. this messages is not really documented (not in the help file). is it on purpose? does this messages will disapare on future gem release? thanks cyrille #N canvas 576 418 596 436 10; #X obj 104 166 gemhead; #X obj 31 89 gemwin; #X msg 31 49 reset \, create \, 1; #X msg 46 69 0 \, destroy; #X obj 104 209 curve 2; #X msg 148 188 3 3 0; #X obj 192 168 gemhead; #X obj 192 211 curve 2; #X obj 284 167 gemhead; #X obj 284 210 curve 2; #X obj 372 169 gemhead; #X obj 372 212 curve 2; #X msg 236 190 3 -3 0; #X msg 328 189 -3 3 0; #X msg 416 191 -3 -3 0; #X obj 148 130 loadbang; #X obj 106 266 gemhead; #X obj 106 309 curve 2; #X obj 194 268 gemhead; #X obj 194 311 curve 2; #X obj 286 267 gemhead; #X obj 286 310 curve 2; #X obj 374 269 gemhead; #X obj 374 312 curve 2; #X obj 150 242 loadbang; #X msg 150 288 3 0 0; #X msg 238 290 0 -3 0; #X msg 330 289 -3 0 0; #X msg 418 291 0 3 0; #X connect 0 0 4 0; #X connect 2 0 1 0; #X connect 3 0 1 0; #X connect 5 0 4 2; #X connect 6 0 7 0; #X connect 8 0 9 0; #X connect 10 0 11 0; #X connect 12 0 7 2; #X connect 13 0 9 2; #X connect 14 0 11 2; #X connect 15 0 5 0; #X connect 15 0 12 0; #X connect 15 0 13 0; #X connect 15 0 14 0; #X connect 16 0 17 0; #X connect 18 0 19 0; #X connect 20 0 21 0; #X connect 22 0 23 0; #X connect 24 0 25 0; #X connect 24 0 26 0; #X connect 24 0 27 0; #X connect 24 0 28 0; #X connect 25 0 17 2; #X connect 26 0 19 2; #X connect 27 0 21 2; #X connect 28 0 23 2;

3 3

YUV processing
by B. Bogart 25 Mar '04

25 Mar '04

Hey all, I remember way back when the yuv_* objects were created that that functionality was going to be integrated into the normal pix_* objects. Did these plans change? I cannot use pix_mask with two YUV streams because it prints out that it does not know how to combine two YUV streams, seems to only accept rgba and grey (hence my issues with pix_rgba). I just tried yuv_mask and it is not in Chris's Gem binary. I can't try it with my own compile (which does include it) because I can't get the film stuff to work. So all that to say: are the yuv* objects deprecated? should pix_mask take YUV and it not doing so is some CVS update issue on my end? Will pix_mask support YUV streams in the future?? Thanks all, Ben

3 5

Re: [PD] [Gem] knowm bugs
by IOhannes m zmoelnig 23 Mar '04

23 Mar '04

beau wrote: > So if I turn off the object translation and rotation adjustments when the > render is stop then it might stop the crashing? > i think so. however, yesterday i spent hours to find this stupid crashing bug, and i really believe that it is hidden somewhere in pd: at least it crashes when reallocating some binbuf - and *only* when some user-input is detected (e.g.: mouse movement) - you don't have much chance to work without mouse; but you could test it with turning rendering on/off without a mouse (e.G: with a [metro]) and it will run stable -- until you move your mouse.... mfg.ads.r IOhannes

1 0

cvs update for osx'ers!
by James Tittle II 23 Mar '04

23 Mar '04

hey gang, ...finally got around to figuring out a bunch of stuff: [gemkeyname] now works correctly (at least on my american laptop keyboard); however, the cross-platform warning still holds (but I'd hope the pushing the 'a' key on any english language keyboard should work on all platforms) [gemwin] finally accepts a "title" for the border/titlebar (if there is one): this may also help with some crashes chris has been seeing with numerous create/destroys (the string is explicitly "cfrelease'd") [gemwin] finally responds to the border message (which turns on/off the title bar): this is a possible solution to the fullscreen problem on 10.3.x, but I haven't tested it, and won't be able to until later tonight (going to a peter bogdanovich lecture!)...anyway, the idea would be to use the offset message to create a window at "mainscreen xsize + 1", so if your desktop is usually 1152x768 (like my tiBook), then do something like [offset 1153 0<... ...of course, this does have a ton of caveats (atm), but most can be handled via the system preferences "Displays" panel... - it won't hide the menu bar, but that can be moved to the screen you don't have as external - it won't change the display's resolution, so you need to do this manually (ie. if you want a 640x480 fullscreen window on the external monitor, make sure you change the external monitor to 640x480 in the display panel, then create a borderless window of size 640x480) - displays don't always have to be on the "right" of the desktop: they can actually be anywhere "around" the desktop, so make sure you position is where you think it should be (I usually keep it attached to the "right" side of the desktop) ...ok, get it a try! jamie ps: btw, I really like how some of the new help/example patches are shaping up!

1 0

gensym, gemkeyname, and char's
by James Tittle II 22 Mar '04

22 Mar '04

hey, (this is kinda directed to IOhannes) ...I'm having some problems getting [gemkeyname] to work right on OSX...at the moment, I'm grabbing a "macCharCode" and passing it on, but the output seems to always be the keyname for the pressed key PLUS 3 trailing characters (non-standard ones, at that)... ...is it possible that gensym is generating these? Does the keyname need to be null terminated? thanx, jamie

2 2

pix_film & pix_movie texturing errors on Linux
by B. Bogart 22 Mar '04

22 Mar '04

Hey All, In trying to test my pix_rgba bug under linux I realized I can't get gem to load videos anymore. (cvs updated today) configures fine, no errors, finds libquicktime and libmpeg3 fine. On create pix_film and pix_movie print: pix_film:: quicktime4linux support pix_film:: libmpeg3 support pix_image works fine. All I get is a white texture after load, as if the frames are not getting textured at all. Any suggestions? This is the same machine I've been running older versions of the CVS without issue... Thanks Ben

2 2

Re: [PD] [Gem] knowm bugs
by IOhannes m zmoelnig 22 Mar '04

22 Mar '04

beau wrote: > hello, > > In the GEM distribution that I am using one of the known bugs is that > > "GEM ONLINE DOCUMENTATION CHAPTER 4: Known bugs > ---------------------------------------------- > > ---------------------------- KNOWN BUGS ----------------------------- > > model crashes when nothing is loaded > --------------- > POSTED 10/25/02" my bugs-list says : model crashes when nothing is loaded --------------- FIXED 01/01/04 POSTED 10/25/02 --------------- BUG: if rendering is started without a model being loaded before, pd crashes ANS: seems to be fixed sime time ago... note the ANSwer section which mentions fixing. > > Concidering that I don't want to wait until a newer version is release how > can I use the program in such it wont crash on me? > it rather: yes you can use the program in such that it will crash on you (but you don't have to) anyhow, make sure you are not using gem-0.87 (non-cvs) this is considered buggy. i strongly encourage people to use the cvs version until the final release of 0.88(8) mfg.ads.r IOhannes

1 0

cvs-check ins
by zmoelnig＠iem.at 21 Mar '04

21 Mar '04

hi in case anybody has noticed and wondered: i have checked in some cahnges to the Geos section, mainly bloating the code. all glu-objects (cone, sphere, cylinder, disk) have been re-written explicitly (GLU is not used anymore), so the rectangle-texturing now works with them. additionally i have done the same to [teapot], so the optional dependency on glut is now removed and the teatpot still available (with rectangle texturing) furthermore i have fixed the texture-code for all other geos that were still missing. (except for the [curve]) mfg.as.dr IOhannes

2 2

FSAA 8 window without gemheads leads to currupted contents. (OSX)
by B. Bogart 21 Mar '04

21 Mar '04

Hey all, Attached is an example patch of a bug I found with chris's current gem compile (march 16th). If you create a window with FSAA 8, with no gemheads in it, or with only gemheads that are not processing the window does not seem to start rendering, and apears currupted. Without FSAA 8 the window behaves as normal. Also with this same compile pix_yuv seems to be the only object that passes texture properly. pix_grey and pix_rgba seem to only pass a still image in a moving video source. See "pix_rgba_bug.pd" This is anoying because I'm trying to use live video with a pix_mask but cannot since it only seems to accept two RGBA streams, but I can't get video passing through as RGBA! (or grey) Last and certainly least... Looks like the first pix_video object one creates grabs the 1394 device. Any subsequent pix_video's get created, but can't grab the device so they just sit there sending (green). Until pix_video supports multiple devices (please please), or even after, it would be useful if all pix_video objects send out the same video no matter which particular instance is attached to the device. This feature would be nice because one may have more than one pix_video in a patch (in multiple chains) but may want to switch on the fly between pix_movie and pix_video (by spigoting the gemchain) Just because there is more than one pix_video in a patch does not mean that they are indeed sending video to the screen... Maybe the last pix_video to be switch on (in a chain) could grab the video..? rather than the first one instanciated... I could use dynamic patching to re-instanciate the "right" pix_video, but that is really ugly... I'm thinking of pix_video as a catch~ for one particular video stream sent through throw~ I think this only effects pix_video since all other pix_ objects can have a local copy of a pix... Thanks Ben #N canvas 455 239 454 304 10; #X obj 23 119 gemwin 30; #X msg 71 85 0 \, destroy; #X msg 43 63 FSAA 8 \, create \, 1; #X obj 65 223 gemhead; #X obj 65 246 square; #X obj 54 171 loadbang; #X msg 62 195 0; #X msg 98 197 1; #X text 133 198 <- turn it on \, and it works.; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 4 0; #X connect 5 0 6 0; #X connect 6 0 3 0; #X connect 7 0 3 0; #N canvas 506 132 647 313 10; #X obj 183 80 gemhead; #X obj 186 106 pix_film; #X obj 212 200 pix_texture; #X obj 215 249 square 4; #X obj 249 106 t f; #X obj 198 172 pix_rgba; #X obj 214 223 alpha; #X obj 24 144 gemwin 30; #X msg 72 110 0 \, destroy; #X msg 241 13 bang; #X obj 249 35 openpanel; #X msg 273 61 open \$1; #X msg 44 88 create \, 1; #X msg 116 46 auto 1; #X obj 103 13 loadbang; #X obj 209 138 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X text 231 139 <- moving image w/out pix_rgba on \, same for pix_grey. Only pix_yuv passes moving image.; #X connect 0 0 1 0; #X connect 1 0 5 0; #X connect 1 2 4 0; #X connect 2 0 6 0; #X connect 4 0 1 1; #X connect 5 0 2 0; #X connect 6 0 3 0; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 10 0 11 0; #X connect 11 0 1 0; #X connect 12 0 7 0; #X connect 13 0 1 0; #X connect 14 0 13 0; #X connect 15 0 5 0;

3 3

Re: [PD] Still with the GEM!
by IOhannes m zmoelnig 12 Mar '04

12 Mar '04

thewade wrote: > IOhannes hast gesagt > > I know that their different packages, but I figured that sence glut runs on GL that glut would install GL as well... Bad assumption. It turns out that xfree86 comes with its own gl drivers. Perhaps I overwrote or failed to verwrite these drivers. the assumption is correct, as you cannot run (or compile) glut without having gl installed. (but glut doesn't come with gl - nor does it come with an operating-system event though one is required to run glut ;-)) >>so let us start from scratch >>compile it with \"gcc gltest.c -lGL\" > > > This compiles to a.out with no complaint! How come this file compiles, but the configure script dies? > indeed, very confusing. > > > Yes, thank you! > > >>simply do \"export LIBS=-L/path/to/my/libraries/that/cannot/be/found\" >>prior to running configure. >>\"export\" is bash-specific, you might have to use something different for >>your shell. > > > configure still dies... hmmm > Is there some way to verify that the configure script is doing the right thing? well, you could go and edit the script and put some debugging information into it. or you could look at the config.log file that is produced during configuration. what does it say (in the last lines ?) and try to compile the gltest.c file with the command you found there. mfg.a.sdr IOhannes

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 2004