GEM-dev

gem-dev@lists.iem.at

2417 discussions

cvs question
by james tittle 28 Dec '05

28 Dec '05

...sorry I'm a bit dense when it comes to cvs, but I'd like to know if there's a simple way to update some files in the multiple_window tag to MAIN/HEAD? I'm thinking in particular about files that have no code changes due to the tag, such as anything in geos, opengl, pix, etc...? Most of the changes are in Base and Controls...I'm dreading the task of merging it by hand, and am looking for an easy way out :-) thanx, jamie

2 1

gem2pdp
by Mathieu Bouchard 22 Dec '05

22 Dec '05

when ./configure looks for Gem sources and doesn't find them, it is misleading: it says one has to change configure.ac and re-run autoconf. However, --with-gemdir also does the job and does not require autoconf. If i make a typo like --with-gem-dir instead of --with-gemdir, ./configure accepts it, ignores it, and doesn't complain about unknown option. Then when I try compiling it: g++ -DPD -O2 -funroll-loops -fomit-frame-pointer -ffast-math -Wall -W -Wno-unused -Wno-parentheses -Wno-switch -DGEM2PDP_VERSION=\"0.6\" -g -I../../pd/src -I. -I../pdp/include -I/home/matju/src/gem-cvs/Gem/src -o pix_2pdp.o -c pix_2pdp.cpp pix_2pdp.cpp: In member function `virtual void pix_2pdp::bangMess()': pix_2pdp.cpp:137: error: jump to case label pix_2pdp.cpp:103: error: crosses initialization of `const int row_length' pix_2pdp.cpp:102: error: crosses initialization of `unsigned char*pixel2' pix_2pdp.cpp:101: error: crosses initialization of `unsigned char*pixel' pix_2pdp.cpp:99: error: crosses initialization of `int cols' pix_2pdp.cpp:98: error: crosses initialization of `int row' pix_2pdp.cpp:155: error: jump to case label pix_2pdp.cpp:103: error: crosses initialization of `const int row_length' pix_2pdp.cpp:102: error: crosses initialization of `unsigned char*pixel2' pix_2pdp.cpp:101: error: crosses initialization of `unsigned char*pixel' pix_2pdp.cpp:99: error: crosses initialization of `int cols' pix_2pdp.cpp:98: error: crosses initialization of `int row' make: *** [pix_2pdp.o] Error 1 _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

3 5

Gemwiki updates
by james tittle 20 Dec '05

20 Dec '05

...trying to revive this, I've made some comments on the following pages: http://puredata.org/Members/zmoelnig/GemWiki/MultipleWindows http://puredata.org/Members/zmoelnig/GemWiki/ContextNames ...nothing major, just fleshing out...but it seems that we may be ready to go ahead and code some more: I'll be working on this tonight (at least getting it back to compiling on osx again!) jamie

4 7

more on multitexturing
by chris clepper 20 Dec '05

20 Dec '05

I spent today trying to get actual multitexturing working using arb_fragment. In order to use shaders with texture units other than the first one the texcoords need to be passed to the remaining units. So if I have a luma/chroma key shader, I need to put a texture on unit 0 and also on unit1. Just enabling them doesn't actually texture them properly though. I added the following to SetVertex() in GemShape: if (state->numTexCoords) { glTexCoord2f(state->texCoordX(curCoord), state->texCoordY(curCoord)); glMultiTexCoord2fARB(GL_TEXTURE1_ARB,state->texCoordX(curCoord), state->texCoordY(curCoord)); } else { glTexCoord2f(tx, ty); glMultiTexCoord2fARB(GL_TEXTURE1_ARB,tx,ty); } Doesn't look so bad right? Well, in order to cover every one of the texture units available, they have to be textured onto properly. So for an eight texture unit GPU that's GL_TEXTURE[0..7]_ARB and so on. Is this something that I should go ahead and do?

2 2

pix_write writing upside down on linux
by cyrille henry 19 Dec '05

19 Dec '05

hello, on my computer, pix_write does write images upside down. looking at the code, i realize that fliping the image is made with an ifdef __apple__ I remove the ifdef, and pix_write now work as expected. i'm on linux + nvidia, and i don't have anymore a windows computer for testing... could someone test pix_write on a windows computer to check when the fliping code should be compiled or not? this is a small problem, but it look to be easy to fix... thanks Cyrille

1 0

Re: [PD] Gem: gemwin object creation problem (Segmentation fault)
by B. Bogart 18 Dec '05

18 Dec '05

Does not mean anything to me, Any ideas? (I've moved this to gem-dev) b. Thomas Hoernlein wrote: > B. Bogart wrote: > >> hello, >> >> Try: >> >> gdb pd -lib Gem >> >> and then load the patch. >> >> When you get the segault you should see this in the terminal: >> >> (gdb) >> >> then do a "bt" and send us the result. >> >> b. >> >> >> On Tue, December 13, 2005 1:53 pm, Thomas Hoernlein said: >> >>> Hi, >>> >>> I'm using Gem version 0.90. It compiled without problems (mandriva >>> linux). When I try to place a gemwin object in pd, pd crashes. >>> pd: line 1: 31796 Segmentation fault >>> It tried versions 0.38-4 and 0.39.2 of pd with similar results. I never >>> had this problem with other pd objects though. >>> Did anyone have the same problem or has any ideas what I could do to fix >>> it? Maybe I'm missing something obvious. >>> >>> Thanks, >>> thomas > > > Hello, > > the debugger shows the following results: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1208138304 (LWP 3805)] > 0x42500150 in glClearColor () from /usr/X11R6/lib/libGL.so.1 > > (gdb) bt > #0 0x42500150 in glClearColor () from /usr/X11R6/lib/libGL.so.1 > #1 0x081629c0 in ?? () > #2 0x081629c0 in ?? () > #3 0xbfffd608 in ?? () > #4 0x080550a3 in canvas_getcurrent () at g_canvas.c:142 > #5 0x00000000 in ?? () > #6 0x08164020 in ?? () > #7 0xb7f67e40 in ?? () from /usr/local/lib/pd/extra/Gem.pd_linux > #8 0xbfffd638 in ?? () > #9 0xb7f67e40 in ?? () from /usr/local/lib/pd/extra/Gem.pd_linux > #10 0x41a00000 in ?? () > #11 0x081629c0 in ?? () > #12 0xbfffd638 in ?? () > #13 0xb7e6efd9 in gemwin::gemwin () from > /usr/local/lib/pd/extra/Gem.pd_linux > #14 0xb7e6efd9 in gemwin::gemwin () from > /usr/local/lib/pd/extra/Gem.pd_linux > #15 0xb7e6f062 in _classgemwin () from /usr/local/lib/pd/extra/Gem.pd_linux > #16 0x0809efa3 in pd_typedmess (x=0x12740, s=0x0, argc=0, argv=0x10) at > m_class.c:732 > > seems to be a flaw with my libGL. Any ideas? > > Thanks, > Thomas > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

1 0

Re: multiple_window: the questions begin!
by IOhannes m zmoelnig 16 Dec '05

16 Dec '05

james tittle wrote: > yallo, > > ...ok, checked it out and started compiling and stuff...immediately ran fine. > into a prob with the triggerMotionEvent(), which apparently takes four admittedly triggerMotionEvent (or rather: all of the hid-things like mouse, keyboard and probably tabled) does not really work yet in multiple_windows. we should discuss this (that is why i put this on gem-dev too): [gemmouse] outputs (as we all know) the mouse-position in the gem-window. now what happens if we have several gemwindows ? i think it there should be a mechanism to get the mouse-coordinates attached to the window the mouse appears in. this is not really possible with [gemmouse]. furthermore, [gemmouse] has several limitations (e.g.: no scroll-wheel support; what about mice with 10 buttons ?) now what should we do about it ? probably the simplest thing (as it is e.g. in pdp) would be to add an outlet to the various gem-windows that would emit the state of the mouse (or of any pointer). we could then build an abstraction (or do it in C) that sends this data to [gemmouse] which would act as a global receiver. as for outlets: personally i think by now(;-)) that it might be best to have just one outlet and prefix the outgoing messages, like [mouse <x> <y> <bt1> <bt2> <bt3>( this way we could always add another parameter to a certain message or just use a new message like [mouse_pos <x> <y>( [mouse_button 3 1( ok, the last 2 don't sound too convincing. anyhow, we need several messages to query things like the dimension of the window (or whatever): [dimen <x> <y>( > args: x, y, w, & h...why were the w & h added? I assume this is width > and height of the window that is being tracked? yes. the idea was to get away from absolute coordinates. i mean, you had to rewrite (well: adjust) your patch everytime you changed the window-dimensions (e.g. developping with a small window and performing with a big one) so i though normalized coordinates would be a cool thing (e.g. 0/0 is always upper left, 1/1 is lower/right) to make it compatible with older versions of [gemmouse] (else this would break every single patch that uses [gemmouse]) i decided to make this behaviour dependent on parameters. so you could give the maximum output range as arguments [gemmouse 1 1] would normalize x & y between 0..1 [gemmouse 10 20] would scale x between 0..10 and y between 0..20 ideally [gemmouse 1] would scale x&y between 0..1 on square windows and between 0..1 and 0..x/y (or the other way around ? thats the big question; i think i t would be better to fix the y-axis and scale x appropriately as this would make "moving objects with the mouse" much easier) on rectangle windows. mfg.as.dr IOhannes

5 16

pix_hit
by davide 15 Dec '05

15 Dec '05

hi list, some week ago I wrote a little gem external to have hit test on images we can check for single points, rectangle areas or lines. the user can define new areas and assign them id, the output of the external is a list of 2 numbers where the first number is the id and the second is the new state. points and rectangles have only 2 states (0=off, 1=on), lines output a float between 0 and 1 where 0 if the hit was in the first point and 1 if the hit was in the second point (a line is created specifying 2 points). I wanted to fix a couple of minor bugs (loading/saving areas, showing areas) before announcing but it seems that i never have spare time, so here it is.. you can find the source code and API here: http://www.davidemorelli.it/dokuwiki/doku.php?id=interfaces:interfaces I'd be happy if the external would be added to GEM's CVS.. ciao, davide.

5 7

just an other videoV4L bugfix
by Georg Holzmann 15 Dec '05

15 Dec '05

Hallo again! in constructor of videoV4l.cpp, m_continue_thread is not initialized, and because the first device is started automatically, it will be stopped (pthread_join) and it crashes if you use Gem together with PDP ... (doesn't crash if you only use GEM ...) anyway, this fixes the problem: (videoV4L.cpp, line 53) --------8<------------8<------------- videoV4L :: videoV4L(int format) : video(format){ #ifdef HAVE_VIDEO4LINUX if (!m_width)m_width=64; if (!m_height)m_height=64; m_capturing=false; m_channel=COMPOSITEIN; m_norm=VIDEO_MODE_AUTO; m_devicenum=DEVICENO; m_continue_thread = false; post("video4linux"); #endif /* HAVE_VIDEO4LINUX */ } --------8<------------8<------------- LG Georg

2 1

udev dv input
by Georg Holzmann 15 Dec '05

15 Dec '05

Hallo gem-devs! As I use udev now I cannot use the dv input in Gem anymore. The problem is the following (i think): with devfs the device was /dev/dv1394 (on my computer) now (udev) the device is on my computer /dev/dv1394/0 The problem is, that /dev/dv1394 is hardcoded in videoDV4L.cpp, so changing line 194: if ((fd=open("/dev/dv1394", O_RDWR)) < 0) { to: if ((fd=open("/dev/dv1394/0", O_RDWR)) < 0) { fixes the problem ! So we would need an additional message, to set the proper device - don't know which one... (pix_video is already very confusing) anyway, I don't have the time to make a clean implementation now - have to make a video till friday ... :) LG Georg

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev