GEM-dev January 2012

gem-dev@lists.iem.at

9 participants
38 discussions

[ pd-gem-Bugs-3281206 ] thin white primitive borders are shown despite texture
by SourceForge.net 12 Jan '12

12 Jan '12

Bugs item #3281206, was opened at 2011-04-08 14:07 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&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: rendering (e.g. display) Group: any operating system >Status: Closed Resolution: None Priority: 7 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: thin white primitive borders are shown despite texture Initial Comment: Sometimes, depending on their size and/or position, rectangles (and I guess other polygons too but I mainly work with rectangles) are shown with a thin white border even if they are textured with a pix that has no white pixel in the proximity of the border, e.g. a completely black image or an image whose pixels close to the border are all black or transparent. This has been there for years, I've always seen this happen since I use gem, across many versions. This happens both with Linux and Windows, i don't know on Mac OS. If a rectangle is moving or changing size, the borders appear and disappear. Most of the time they are absent, I mean the values of position and size that cause the borders to appear are just a small fraction of the total. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 13:41 Message: as for [gemframebuffer], i really don't know why CLAMP is used rather than CLAMP_TO_EDGE; it was most likely forgotten... but apart from that, CLAMP_TO_EDGE is already used (and that's at least since 0.91) ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-08-16 12:25 Message: hello, yes, GL_CLAMP_TO_EDGE is better than GL_CLAMP. The grep does not say a lot about the code. if you have a look in pix_texture.cpp : if (type) m_repeat = GL_REPEAT; else { if(GLEW_EXT_texture_edge_clamp) m_repeat = GL_CLAMP_TO_EDGE; else m_repeat = GL_CLAMP; } when repeat mode = 0, then m_repeat is GL_CLAMP_TO_EDGE if possible, or GL_CLAMP if not. it's the same about pix_imageInPlace and pix_cubemap. it's not the same for framebuffer, but there certainly is a good reason for this. c ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 10:15 Message: Guessing at the cause here, but I'm led to believe GL_CLAMP is mostly wrong, and GL_CLAMP_TO_EDGE is to be preferred almost always... http://www.opengl.org/wiki/Common_Mistakes#Texture_edge_color_problem claude@zebimus:~/code/pd-gem$ grep -Rwn "GL_CLAMP" . | grep -v \\.svn ./Gem/ChangeLog:4473: "GL_CLAMP" when doing rectangle-textures, as they will ignore ./Gem/src/Pixes/pix_imageInPlace.cpp:216: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_cubemap.cpp:365: m_repeat = GL_CLAMP; ./Gem/src/Pixes/pix_texture.cpp:118: // NPOT: GL_CLAMP, GL_CLAMP_TO_EDGE, GL_CLAMP_TO_BORDER ./Gem/src/Pixes/pix_texture.cpp:690: m_repeat = GL_CLAMP; ./Gem/src/Gem/glew.h:698:#define GL_CLAMP 0x2900 ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ./Gem/src/Utils/GLUtil_generated.h:86: if (!strcmp(name, "GL_CLAMP")) return GL_CLAMP; ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:42: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:43: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:69: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/test/FTTextureGlyph-Test.cpp:70: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:128: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); ./GemLibs/FTGL/src/FTGLTextureFont.cpp:129: glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); ./GemLibs/FTGL/include/FTGLTextureFont.h:85: * GL_TEXTURE_WRAP_S = GL_CLAMP ./GemLibs/FTGL/include/FTGLTextureFont.h:86: * GL_TEXTURE_WRAP_T = GL_CLAMP Incidentally, could these better be ...i instead of ...f function calls? claude@zebimus:~/code/pd-gem$ grep -Rn "glTexParameterf" . | grep -v \\.svn | grep -v GL_TEXTURE_PRIORITY | grep -v src/openGL | grep -v glew\.h | grep -v build/ | grep -v GEM ./Gem/src/Pixes/pix_imageInPlace.cpp:156: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_imageInPlace.cpp:157: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:112: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:113: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:114: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:115: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:347: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:348: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_cubemap.cpp:371: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_cubemap.cpp:372: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:90: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:91: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:365: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_snap2tex.cpp:366: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:137: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:138: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:139: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:140: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:270: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:271: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:657: glTexParameterf(m_textureType, GL_TEXTURE_MAG_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:658: glTexParameterf(m_textureType, GL_TEXTURE_MIN_FILTER, m_textureQuality); ./Gem/src/Pixes/pix_texture.cpp:696: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_S, m_repeat); ./Gem/src/Pixes/pix_texture.cpp:697: glTexParameterf(m_textureType, GL_TEXTURE_WRAP_T, m_repeat); ./Gem/src/Pixes/pix_movieOS.cpp:271: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT); ./Gem/src/Pixes/pix_movieOS.cpp:272: glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT); ./Gem/src/Controls/gemframebuffer.cpp:284: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_S, GL_CLAMP); ./Gem/src/Controls/gemframebuffer.cpp:285: glTexParameterf(m_texTarget, GL_TEXTURE_WRAP_T, GL_CLAMP); ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 09:33 Message: it's hardware/driver specific as the openGL standard doesn't specify exactly how it ought to be done (afair); i mainly follow cyrille's arguing here. the workaround is to e.g. set "repeat" mode and/or the "quality" mode of texture. you can apply a global defaul by adding lines for "texture.quality" and "texture.repeat" to your gem.conf; something like: <gem.conf> texture.quality 0 </gem.conf> ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-08-16 09:27 Message: Sorry it was me asking the last question (damn the fake "remember me" checkbox, I reported that but the admins like the way it is) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-08-16 09:24 Message: What hardware/driver is this specific to? What's the workaround in gem.conf? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-08-16 09:01 Message: given that the problem is hardware/driver specific, there is a workaround _and_ the workaround can be done globally using gem.conf (in >=0.93), i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-23 08:39 Message: Does the hardware really interpolate textures the wrong way? Are we sure Gem is asking the hardware the right thing? If "repeat" is the fix, i suspect it may mask the issue (i.e. make it less evident in some but not all situations) rather than fix it, but I haven't tried it actually. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-08 15:35 Message: This is not a gem problem. it's the way the hardware interpolate a texture. i don't remember the exact configuration, but changing the default value of "quality" and/or "repeat" of pix_texture change can fix this problem. since it's not gem fault, and gem offer a solution, i think this can be closed. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-08 14:10 Message: I hope it is ok to rise the priority. Though this is an old bug, it is a real showstopper in a range of situations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_…

1 0

[ pd-gem-Bugs-3308535 ] pix_image eats a lot of CPU even when idle
by SourceForge.net 12 Jan '12

12 Jan '12

Bugs item #3308535, was opened at 2011-05-27 12:50 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3308535&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: Pixes (pix_ objects) Group: linux >Status: Closed Resolution: Fixed Priority: 8 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_image eats a lot of CPU even when idle Initial Comment: If you have many [pix_image] objects in a patch, even if none of them loads any image and even if none of them is connected to any gemhead, Pd will consume a lot of CPU, apparently proportional to the number of [pix_image] instances. On a dual core machine, the amount of CPU consumption can exceed 100% of a core, so I guess the issue must be in some part of the code that is threaded - hopefully this may help to track down the issue. The attached patch (64 pix_images) eats 150% of my intel core duo t9300 on Ubuntu 10.04 while the patch is doing absolutely nothing. This makes it impossible to have a handful of pix_image objects with preloaded images and dynamically choose which one to show, just to name one thing that can't be done and which should not be resource-demanding. This kills any project working with images. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-07-15 01:35 Message: the threaded loading in [pix_image] has been totally rewritten for 0.93 (current SVN) and i believe that this has also fixed this issue ---------------------------------------------------------------------- Comment By: Katja (katjav) Date: 2011-06-08 04:08 Message: Confirm this issue for Debian Squeeze. pix_image causes a cpu load of ~4% per instance when thread loading is enabled. Debian Squeeze Panasonic CF 74 with Intel integrated 945GM Pd-extended 0.42.5 Gem 0.93 Since thread loading is enabled by default, patches with multiple pix_image created on other systems (where this issue does not exist) can not be used without modification. If the pix_image cpu load issue is common for Linux, the object should initialize with threadMess(0) instead of threadMess(1) as long as the issue is not solved. I recompiled Gem with this small change in the code and can now load arbitrary patches with multiple pix_image. Cross-platform patch sharing would be better served by source and binary distributions with this initialisation, until the issue can be solved in a more satisfactory way. Katja Vetter ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-05-27 13:12 Message: I've just realised that if I send [pix_image] a "thread 0" message it stops eating CPU. So it is the threaded mode. Note that there's no need to actually load an image to trigger the issue: just because threaded mode is enabled, it is always wasting CPU. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3308535&group_…

1 0

[ pd-gem-Bugs-3323319 ] problem with flv file (libaviplay & gmerlin)
by SourceForge.net 12 Jan '12

12 Jan '12

Bugs item #3323319, was opened at 2011-06-20 11:15 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3323319&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: Pixes (pix_ objects) Group: linux >Status: Closed Resolution: Fixed Priority: 3 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: problem with flv file (libaviplay & gmerlin) Initial Comment: When I try to play the linked flv files with pix_film, I get only green garbage. I guess it is playing it with libaviplay, since I see the following on the console: pix_film:: quicktime support pix_film:: libmpeg3 support pix_film:: libaviplay support [pix_film]: opening /home/teo/lavoro/nico_baixes/new/test_pages/proj1/video/pitchalt.flv with format 1908 [pix_film]: ... [pix_film]: ... [pix_film]: ... quicktime failed[pix_film]: ... MPEG3 failed[pix_film]: ... [pix_film]: loaded file: ......./pitchalt.flv with 2147483647 frames (320x213) at 0.000000 fps There's no error message. The file plays fine on other players. I guess the issue may be in libaviplay itself... The test file: http://totalwebvideo.com/pitchalt.flv ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-02 03:35 Message: i checked again, and current Gem (at least the development version) CAN play the given flv using the GMERLIN backend. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-06-21 01:37 Message: i checked with "aviplay" (which comes in the 'avifile-player' package and is a cmdline player for libavifile/ilbaviplay) and indeed it is unable to play this file. so your problem seems to be with libavifile unfortunately, the file also does not play with the GMERLIN backend, which i would expect to work (esp, since the standalone player 'gmerlin' _can_ play this file) so there _are_ issues with this file and Gem's playback capabalities. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3323319&group_…

1 0

[ pd-gem-Bugs-3368208 ] 'make install' on Mac OS X tries to install gem_videoV4L2.so
by SourceForge.net 12 Jan '12

12 Jan '12

Bugs item #3368208, was opened at 2011-07-15 13:33 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3368208&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: osx >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: 'make install' on Mac OS X tries to install gem_videoV4L2.so Initial Comment: On Mac OS X 10.5.8/Intel using Fink, running 'make install' dies when it tries to make a symlink gem_videoV4L2.so but the file does not exist. Oddly enough gem_videoV4L.so exists and is successfully linked to: gem_recordV4L2.so: creating convenience link from /Volumes/share/code/pure-data/trunk/externals/Gem/src/plugins/recordV4L2/.libs to ../../.. Making all in videoDC1394 Making all in videoDS Making all in videoDV4L Making all in videoDarwin gem_videoDarwin.so: creating convenience link from /Volumes/share/code/pure-data/trunk/externals/Gem/src/plugins/videoDarwin/.libs to ../../.. Making all in videoSGI Making all in videoUNICAP Making all in videoV4L gem_videoV4L.so: creating convenience link from /Volumes/share/code/pure-data/trunk/externals/Gem/src/plugins/videoV4L/.libs to ../../.. Making all in videoV4L2 gem_videoV4L2.so: creating convenience link from /Volumes/share/code/pure-data/trunk/externals/Gem/src/plugins/videoV4L2/.libs to ../../.. make[5]: *** [convenience-link] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-07-18 08:22 Message: i changed the build-system so that now videoV4L* are not build at all if it doesn't make sense; also the convenience-symlinks fail more gracefully ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3368208&group_…

1 0

[ pd-gem-Bugs-3400070 ] README.txt does not reflect version
by SourceForge.net 12 Jan '12

12 Jan '12

Bugs item #3400070, was opened at 2011-08-28 23:43 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3400070&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: any operating system >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Winfried Ritsch (ritsch) Assigned to: Nobody/Anonymous (nobody) Summary: README.txt does not reflect version Initial Comment: If checking out branch 0.93 from svn, the README.txt still says: This is 0.91 even the CHANGELOG reflects the 0.93, but there is no note about 0.93.1 (is it the svn) which reflects the git submit. If git is preferred, please give it a note with a common commandline how to clone a branch or the trunk. Anyway thanks for the update. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-11-02 02:12 Message: thanks i removed the version from README.txt (currently only in git), so there shouldn't be any more confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3400070&group_…

1 0

[ pd-gem-Bugs-3402822 ] pix_film (gmerlin) crashes with animated gifs
by SourceForge.net 12 Jan '12

12 Jan '12

Bugs item #3402822, was opened at 2011-09-01 13:39 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3402822&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: Pixes (pix_ objects) Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: pix_film (gmerlin) crashes with animated gifs Initial Comment: when trying to open an animated gif (as attached) with [pix_film], Gem crashes. the problem might be within gmerlin-avdecoder: <snap> verbose(6): [pix_film]: trying to add \'gmerlin\' as backend [pix_film]: gmerlin support saved to: /home/zmoelnig/src/git/Gem/Gem/filmer.pd [pix_film]: opening /home/zmoelnig/src/git/Gem/Gem/animated.gif with format 1908 verbose(5): [pix_film:demuxer] Detected GIF format Program received signal SIGSEGV, Segmentation fault. 0xb6ef847a in gavl_frame_table_num_frames () from /usr/lib/libgavl.so.1 </snap> <bt> (gdb) bt #0 0xb6ef847a in gavl_frame_table_num_frames () from /usr/lib/libgavl.so.1 #1 0x081c3820 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) </bt> ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-10-27 08:58 Message: i checked with gmerlin-avdecoder upstream, and indeed it was missing "seeking" for animated gifs. i submitted a fix for the problem, which (once it's accepted) will magically make animated gifs work properly in Gem. i think i can therefore close this ticket. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-09-01 23:44 Message: indeed there was a problem in Gem. unfortunately gifs still cannot be played in random access mode. (and in threaded decoding they usually will be decoded before all the frames have been displayed) ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-09-01 13:40 Message: but then: gmerlin_play does _not_ crash on the same file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3402822&group_…

1 0

[ pd-gem-Bugs-3412354 ] pix_film/pix_image fail to create on w32 if plugins fail
by SourceForge.net 12 Jan '12

12 Jan '12

Bugs item #3412354, was opened at 2011-09-21 08:30 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3412354&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: Pixes (pix_ objects) Group: win32 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Nobody/Anonymous (nobody) Summary: pix_film/pix_image fail to create on w32 if plugins fail Initial Comment: this is with Gem-0.93.1 on win7 (from the installer) QuickTime is NOT installed creating a [pix_image data/bla.jpg] fails to create: - plugins installed: all but imageMAGICK (which crashes) - i think that imageQT throws an error which is caught only by the object creator (which fails creation) creating [pix_film] fails as well (because QuickTime is not installed) - plugins installed: default ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-10-31 07:43 Message: should be fixed with revs.0c9830451f0,c4ff30add0b ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3412354&group_…

1 0

[ pd-gem-Bugs-3427015 ] pix_texture right inlet / texture quality
by SourceForge.net 12 Jan '12

12 Jan '12

Bugs item #3427015, was opened at 2011-10-21 13:04 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3427015&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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: pix_texture right inlet / texture quality Initial Comment: when using pix_texture right inlet, the quality is not set during the rendering process. strange things can happend. see exemple patch. initially reported on the list by Guido Tamino ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-10-24 12:22 Message: should be (somewhat) fixed with rev:6847daa9de04a931f1 ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-10-24 11:54 Message: confirmed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3427015&group_…

1 0

[ pd-gem-Bugs-3427015 ] pix_texture right inlet / texture quality
by SourceForge.net 12 Jan '12

12 Jan '12

Bugs item #3427015, was opened at 2011-10-21 13:04 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3427015&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: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: pix_texture right inlet / texture quality Initial Comment: when using pix_texture right inlet, the quality is not set during the rendering process. strange things can happend. see exemple patch. initially reported on the list by Guido Tamino ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-10-24 12:22 Message: should be (somewhat) fixed with rev:6847daa9de04a931f1 ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-10-24 11:54 Message: confirmed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3427015&group_…

1 0

[ pd-gem-Bugs-3430181 ] examples/04.pix/05.film.pd references non-existing pix_rgba
by SourceForge.net 12 Jan '12

12 Jan '12

Bugs item #3430181, was opened at 2011-10-29 11:33 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3430181&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: documentation Group: linux >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Ricardo Fabbri (ricardofabbri) Assigned to: Nobody/Anonymous (nobody) Summary: examples/04.pix/05.film.pd references non-existing pix_rgba Initial Comment: using latest Gem.git with pd extended from svn. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-10-30 13:32 Message: took me a while to understand that you meant, that [pix_rgba] is mentioned in the comment but there is no such object in the patch (rather than a [pix_rgba] instance that couldn't be created) fixed in git ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3430181&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 January 2012