GEM-dev October 2008

gem-dev@lists.iem.at

10 participants
8 discussions

Timing and PD....
by B. Bogart 31 Oct '08

31 Oct '08

Hey all, I'm having more and more problems with sync in PD. By sync I mean that parts of my patches have processing delays that mess up timing. In general I've been using buffers and delays to keep things working. This approach is not very scalable. I find myself using the "timer" object all the time to see if there is a processing delay I have to worry about. That is in cases where there is a bang saying an operation is done. Two examples I'm working on now (in Gem): First there is a delay between sending a message and the pix_buffer to store, and then again for pix_buffer_read to read the pixels. The delay is long enough that trigger does not work, there needs to be a delay to make sure the image in the buffer is the right one. (sometimes as much as 200ms) A second example is that I'm using pix_share and and second PD instance to offload some CPU usage. Making sure the image sent to that PD instance and the image received later in the chain is difficult. I'm not writing for specific advice, hence the generalities, but wanted to start a discussion on the issue. What is the long-term solution for PD to solve these issues? Should all objects that introduce a delay send a bang when they are complete? (for example pix_buffer? Of course an additional delay occurs when when the pix_buffer is written to memory and when it gets to the gfx card for display. I'm banging my head over these issues a lot lately and wonder if there is a better approach. Back to attempting kludging a solution. .b.

6 11

alpha blending of patterns
by Conor Higgins 30 Oct '08

30 Oct '08

Hi I am having a slight problem and cant seem to find the remedy for it just yet... What I am doing is creating an optical illusion system for an artist. The idea is that when the person is moving then they will appear in the pattern as a silhouette, but will have a pattern on them, and when their movement is minimal then they will disappear into the canvas again. It is a simple idea but there is one thing catching me out. I am trying to map a pattern to just the colour black but alas am having no good results. Has anyone got an idea of how to just overlay on a single colour? Thanks, Conor Higgins

2 1

[ pd-gem-Bugs-2208370 ] pix_histo does not clear table when there is no texture
by SourceForge.net 29 Oct '08

29 Oct '08

Bugs item #2208370, was opened at 2008-10-29 22:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2208370&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pix_histo does not clear table when there is no texture Initial Comment: I'm using pix_histo to do hist analysis on frames in a pix_buffer. If the buffer slot is empty (that is it does not contain any texture) the pix_histo table stays the same. I think if the chain has no texture data pix_histo should produce a zeroed table. Currently it just keeps the data that was last in the table (from the last slot with an image in it). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2208370&group_…

1 0

build on ubuntu 8.10
by patco 29 Oct '08

29 Oct '08

hello, I have a problem for building gem on ubuntu 8.10, the build system complains for existing missing files. configure: error: GL (headers) not found! you need openGL!!! $ apt-cache show xlibmesa-gl-dev Package: xlibmesa-gl-dev Priority: optional Section: libdevel Installed-Size: 24 Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian X Strike Force <debian-x(a)lists.debian.org> Architecture: all Source: xorg Version: 1:7.4~5ubuntu3 Depends: libgl1-mesa-dev, x11-common Filename: pool/main/x/xorg/xlibmesa-gl-dev_7.4~5ubuntu3_all.deb Size: 960 $ ls /usr/include/GL |grep gl.h gl.h

2 3

[ pd-gem-Bugs-2192358 ] cannot focus border 0 gemwin in xfce
by SourceForge.net 24 Oct '08

24 Oct '08

Bugs item #2192358, was opened at 2008-10-24 17:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2192358&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: cannot focus border 0 gemwin in xfce Initial Comment: with "border 0, create, 1"--[gemwin] I cannot focus the GEM window, so cannot use gemkeyname (nor in fact move the window using the window manager, etc...) this is with xfce4/xfwm4 and gem 0.91.1 some googling tells me that GEM should use some other method for disabling borders than what it does: ----8<---- xwininfo: Window id: 0x2c00004 "GEM" Absolute upper-left X: 0 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 500 Height: 500 Depth: 24 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x2c00003 (not installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: yes Corners: +0+0 -780+0 -780-268 +0-268 -geometry 500x500+0+0 ----8<---- "" You have the answer here : Override Redirect State: yes Override redirect windows are not managed by the WM "" -- http://bugzilla.xfce.org/show_bug.cgi?id=1877#c8 i'm not sure what the correct method of telling the window manager not to have borders is, though... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2192358&group_…

1 0

removing inactive devs from sf-project (here too...)
by IOhannes m zmoelnig 16 Oct '08

16 Oct '08

hi all while initiating a cleanup of the pure-data project, i had a look at pd-gem as well. of 12 registered developers, a total of 7 devs have committed at least once since 2006-10-10. 6 devs have not contributed to the repository since then. (one of the devs has been taken off the list since then) here's the list of inactive devs: bbogart, dheck, doelie, ggeiger, timblech, tmusil i will send an email asking them to opt out of a removal from the pd-gem sf-project. below is the text (slightly modified version of the text i want to use for the pure-data project) fmgasd IOhannes -- Hi, you are a registered developer at the "pd-gem" sourceforge project, which means that you have write access to the repository hosted there. our project currently has 12 registered developers, some of them being inactive. as the administrator of the project, i would like to reduce the number of developers to the active ones. since you haven't committed anything within the last two (2) years, you are considered to be "inactive", and therefore i would like to remove you from the list of developers. if you ever feel like you need developer status (=write access to the repository) again, just send an email to the pd-dev mailinglist. (this is the main reason why i dare to send out this email: getting write access is so simple that people don't lose a privilige if they are removed from the list of developers) if you feel that this is totally unjustified, please tell me within the next week and i will not remove you from the list of active-developers mfg.asdr IOhannes _______________________________________________ Pd-dev mailing list Pd-dev(a)iem.at http://lists.puredata.info/listinfo/pd-dev

2 1

ATI linux drivers vs C++ exceptions [SOLVED]
by Claude Heiland-Allen 04 Oct '08

04 Oct '08

Hi, I'd been having horrible issues with Pd crashing with a segfault in __cxa_allocate_exception() when using both Gem and GridFlow, preventing me using the Gem<=>GridFlow bridge: pd -lib gridflow -lib Gem => no crash pd -lib Gem -lib gridflow => segfault Turns out that it's a bug in the ATI OpenGL implementation, and the suggested workaround (to link libstdc++ before opengl libraries) works better than I had hoped: http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception#Workaround Using the attached source, I can do: pd -lib libstdcpp -lib Gem -lib gridflow => no crash Hope this helps others in a similar predicament. Claude -- http://claudiusmaximus.goto10.org libstdcpp.pd_linux: libstdcpp.c gcc -shared -o libstdcpp.pd_linux libstdcpp.c -lstdc++

1 0

Re: [GEM-dev] V4l2 :: Debugging an issue with cx8800 card.
by B. Bogart 01 Oct '08

01 Oct '08

I have made progress. I've managed to get my card working in Gem with some minor changes to the code. I'm not sure what this code does though, so I'm not sure what the longer term effect will be. I'm sending this to the v4l list as you all are the best to advice on a proper solution to this issue. I've attached the original, and the hacked version. Basically the hacked version ignores all errors when running the following command: xioctl (m_tvfd, VIDIOC_DQBUF, &buf) What does this command actually do? Why are there two instances in the capture function? I can use the card at 640x480. The result is the frame-rate is horrid compared to mplayer (which I suppose makes sense based on those removed error reports) and also using the V4L1 w/ a bt8x8 card. Does this change give a hint as to what is causing the problem? What is the proper way to fix the issue, rather than commenting out error codes? Thanks all, B. Bogart

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev October 2008