GEM-dev July 2008

gem-dev@lists.iem.at

10 participants
11 discussions

[ pd-gem-Bugs-2032488 ] configure does not detect missing glu-headers
by SourceForge.net 30 Jul '08

30 Jul '08

Bugs item #2032488, was opened at 2008-07-30 11:22 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=2032488&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: build-system Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: configure does not detect missing glu-headers Initial Comment: just tried to compile Gem on a fresh install of Debian/GNU (PowerPC) the libglu-devel package (libglu1-mesa-dev) was missing. "configure" did not complain and instead succeeded. "make" of course miserably failed! installing the missing package fixed this, but it would be nice if configure would issue an error if it misses a certain package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2032488&group_…

1 0

Re: [GEM-dev] artoolkit
by cyrille henry 29 Jul '08

29 Jul '08

patrick a Ã©crit : > hi cyrille, > > i think pix_artoolkit was ported to gem by IOhannes(?). also i know that > Johannes Taelman did use it on windows (compiled with visual something). > > so it should work, but not here (linux). ah. sad. > pix_artoolkit is loading fine > in pd, i can also open a marker, but it's not reporting at all. ok. > > there's so much interesting project in this field. that would be really > neat to have it under pd / gem. there's also bazar that can use any > marker (picture, even on a t-shirt). * ok, thanks. i'll have a look at bazar ++ Cyrille > > too bad about 2 projects: artoolkitplus and artag. artoolkitplus is no > longer updated since june 2006 and replaced with a money software. artag > like stated on the website: Still negotiating and waiting for the > license rights for ARTag from the NRC. Outcome now uncertain. > > keep us updated please, > pat > > * http://cvlab.epfl.ch/software/bazar/ > >

4 3

artoolkit
by cyrille henry 26 Jul '08

26 Jul '08

hello, did someone successfully build and use pix_artoolkit? any advice? thanks Cyrille

1 0

subversion again...
by IOhannes m zmoelnig 23 Jul '08

23 Jul '08

hi all. to lighten my growing frustration with CVS i would like to propose again to switch the Gem development from CVS to SVN. the main reason for me right now is, that my personal online-time has been greatly reduced within the last weeks (and it is not clear whether it will grow again); with CVS i unfortunately need to be online for quite everything (even to query whether i have modified any files), this is better with SVN (at the expense of harddiskspace) other boni: - the main Pd-repository is now using subversion too - all the fancy stuff about renaming files, fixing execution-bits, deleting unused directories and so on - standardized format for links to the current (or a certain) development branch; the main-branch could be https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/Gem/trunk; what would it be on CVS? cvs://cvs.gem.iem.at/cvsroot/pd-gem/Gem ? (it's probably readable by humans, but not standardized and thus not readable by machines) - some of the remaining GemLibs (e.g. FTGL) are now also hosted in svn-repositories upstream, so we could more easily include them. i would suggest to keep the repository at sourceforge (why bother with setting up our own) plllleazzzze!! fgam,sdr IOhannes

3 4

Re: [GEM-dev] Trouble about Gem with MIDI controller
by Marco Liuni 11 Jul '08

11 Jul '08

> >> the correct way to use these objects is really: >> >> [pix_film] >> | >> [pix_motionblur] >> | >> [pix_texture] > I deleted the [pix_motionblur], I was not using it anymore: now I've > done as you told me... WOW > > I wouldn't believe my patch could run this way :-))) > > Thank you so much list. > > Marco Liuni >> >> >> anyhow, good it works now. >> >> fgamsdr >> IOhannes >

1 0

Re: [GEM-dev] Trouble about Gem with MIDI controller
by marco liuni 10 Jul '08

10 Jul '08

Thank you very much for your attention, now the patch runs smoothly and MIDI controlling is quick. I've tried like this: - I've converted the videos with the AIC codec; - I've added the -nrt flag; - I've allowed double buffering on the window with a 50-milliseconds swap time; - I've removed the [pix_motionblur], even if I didn't experienced that Pd crash; - I've put [pix_film]--[pix_texture] instead of [pix_movie]. As I was in a hurry I've not changed things one at once, so I'm not sure which was the main trouble, but I'll check and tell you if it's useful. All the best, Marco. Jack wrote: > Hmm, when i create the GEM window, Pd crash. > I need to remove [pix_motionblur] in video_movie.pd to create GEM window. > ++ > > Jack > > > Le 8 juil. 08 à 17:27, chris clepper a écrit : > > If this is on OSX: >> >> Try using the -nrt flag for Pd startup. Also, the Apple Intermediate >> codec works better than JPEG for multiple clips. >> >> On Tue, Jul 8, 2008 at 8:07 AM, marco liuni <leehooni(a)gmail.com <mailto: >> leehooni(a)gmail.com>> wrote: >> >> Hi, >> >> I'm performing a patch which uses four pix_movie objects with >> 720x576 JPEG .mov videos at 25 fps, with pd extended 40.3 on a >> MacBook Pro. >> >> As I create the Gem window, the MIDI controller I use to set >> colour and movements starts being really slow, I have a visible >> latency on the values displayed in the numbox related and on all >> the video processing. The Cpu usage is never more than 35%, so >> I've found this quite unusual. >> >> Anyone can help me? Thank you very much. >> Marco Liuni >> >> _______________________________________________ >> GEM-dev mailing list >> GEM-dev(a)iem.at <mailto:GEM-dev@iem.at> >> http://lists.puredata.info/listinfo/gem-dev >> >> >> _______________________________________________ >> GEM-dev mailing list >> GEM-dev(a)iem.at <mailto:GEM-dev@iem.at> >> http://lists.puredata.info/listinfo/gem-dev >> > >

2 1

Trouble about Gem with MIDI controller
by marco liuni 09 Jul '08

09 Jul '08

Hi, I'm performing a patch which uses four pix_movie objects with 720x576 JPEG .mov videos at 25 fps, with pd extended 40.3 on a MacBook Pro. As I create the Gem window, the MIDI controller I use to set colour and movements starts being really slow, I have a visible latency on the values displayed in the numbox related and on all the video processing. The Cpu usage is never more than 35%, so I've found this quite unusual. Anyone can help me? Thank you very much. Marco Liuni

4 8

Re: [GEM-dev] "auto 1, 1"--[alpha] with double [gemhead] idiom
by Claude Heiland-Allen 06 Jul '08

06 Jul '08

Hi Matthias, I hope you don't mind me sending this reply to the list too. Matthias Neuenhofer wrote: > Hi Claude, > > itÅ½s not a bug in Gem the depth sorting follows the render order. Normal > openGL behaviour. That's what I suspected, and in that case maybe the wording of [alpha]'s help patch could be better: "" Inlet 1: message "auto 1" | "auto 0" turn on/off automatic depth detection "" I thought this would cache all objects following the [alpha] and sort them by depth automatically, or something. Now I'm not sure what the "auto $1" message does at all. Reading carefully the large paragraph I see it says: "" Be aware that the rendering order matters, so you probably want to set the gemhead order number high so that the object is rendered after all of the non-alpha blended ones. "" Maybe this could be made more explicit, saying render order of alpha-blended objects matters as well as alpha vs non-alpha objects. > In the second way you render your patch itÅ½s well working. Sure, but naturally the "real patch" has much more complicated geometry, it would be a major pain in Pd as far as I can tell to do some kind of 3 pass rendering, where the first pass gets the depth of each object, the second pass sorts by depth, and the third pass actually draws them. I guess I'm too ambitious :) Thanks, Claude > http://www.opengl.org/resources/faq/technical/transparency.htm > When using depth buffering in an application, you need to be careful > about the order in which you render primitives. Fully opaque primitives > need to be rendered first, followed by partially opaque primitives in > back-to-front order. If you don't render primitives in this order, the > primitives, which would otherwise be visible through a partially opaque > primitive, might lose the depth test entirely. > > In a double gemhead patch i see no chance to change. Otherwise with set > messages to gemhead. > > lg > Matthias > > > Am 02.07.2008 um 19:37 schrieb Claude Heiland-Allen: > >> Hi, >> >> The attached patch "double-gemhead-auto-alpha.pd" doesn't work as I >> expect (I don't get any automatic depth sorting). Is there any >> suggested workaround for repetition with auto alpha depth sorting or >> is this a bug in Gem? >> >> Thanks, >> >> >> Claude >> -- >> http://claudiusmaximus.goto10.org

1 0

"auto 1, 1"--[alpha] with double [gemhead] idiom
by Claude Heiland-Allen 03 Jul '08

03 Jul '08

Hi, The attached patch "double-gemhead-auto-alpha.pd" doesn't work as I expect (I don't get any automatic depth sorting). Is there any suggested workaround for repetition with auto alpha depth sorting or is this a bug in Gem? Thanks, Claude -- http://claudiusmaximus.goto10.org #N canvas 0 0 361 556 10; #X obj 5 54 gemwin; #X msg 24 7 create \, 1; #X msg 26 30 0 \, destroy; #X obj 81 94 gemhead; #X obj 81 157 alpha; #X obj 15 94 loadbang; #X msg 81 212 5; #X obj 81 239 until; #X obj 81 187 t b b; #X msg 160 223 0; #X obj 81 264 t b b; #X obj 142 265 f; #X obj 186 266 + 1; #X obj 81 299 gemhead; #X obj 11 239 loadbang; #X msg 11 263 0; #X obj 81 432 color; #X obj 225 303 / 5; #X msg 225 330 \$1 1 1; #X obj 225 353 hsv2rgb; #X obj 81 458 cube; #X obj 81 330 translate 0 0 0 -1; #X obj 199 117 hradio 15 1 0 2 empty empty empty 0 -8 0 10 -262144 -1 -1 0; #X obj 199 68 loadbang; #X msg 199 90 0; #X msg 15 123 auto 1 \, 1; #X msg 225 379 \$1 \$2 \$3 0.15; #X text 6 489 Expect: depth sorting of 5 cubes => result same; #X text 7 510 Get: no depth sorting => results differ; #X msg 168 186 set 0; #X msg 223 186 set 4; #X msg 194 234 1; #X msg 227 235 -1; #X obj 199 144 sel 0 1; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 4 0; #X connect 4 0 8 0; #X connect 5 0 25 0; #X connect 6 0 7 0; #X connect 7 0 10 0; #X connect 8 0 6 0; #X connect 8 1 9 0; #X connect 9 0 11 1; #X connect 10 0 13 0; #X connect 10 1 11 0; #X connect 11 0 12 0; #X connect 11 0 17 0; #X connect 11 0 21 1; #X connect 12 0 11 1; #X connect 13 0 21 0; #X connect 14 0 15 0; #X connect 15 0 13 0; #X connect 16 0 20 0; #X connect 17 0 18 0; #X connect 18 0 19 0; #X connect 19 0 26 0; #X connect 21 0 16 0; #X connect 22 0 33 0; #X connect 23 0 24 0; #X connect 24 0 22 0; #X connect 25 0 4 0; #X connect 26 0 16 1; #X connect 29 0 9 0; #X connect 30 0 9 0; #X connect 31 0 12 1; #X connect 32 0 12 1; #X connect 33 0 29 0; #X connect 33 0 31 0; #X connect 33 1 30 0; #X connect 33 1 32 0;

2 4

[ pd-gem-Bugs-2008988 ] [separator] prints "GL: invalid enumerant" every frame
by SourceForge.net 02 Jul '08

02 Jul '08

Bugs item #2008988, was opened at 2008-07-02 17:02 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=2008988&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: [separator] prints "GL: invalid enumerant" every frame Initial Comment: Using: pd-0.41-4 Gem-0.91.1 Linux minimus 2.6.24-1-686 #1 SMP Thu May 8 02:16:39 UTC 2008 i686 GNU/Linux OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI MOBILITY RADEON 9600/9700 Series OpenGL version string: 2.1.7537 Release A patch like: [gemhead] | [separator] | [cube] leads to "GL: invalid enumerant" printed every(!) frame. A patch like: [gemhead] | [cube] doesn't print anything unusual. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2008988&group_…

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 July 2008