GEM-dev June 2011

gem-dev@lists.iem.at

11 participants
54 discussions

Gem: build-system updates and image plugins
by IOhannes m zmoelnig 08 Jun '11

08 Jun '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 just to inform you: the build-system of Gem has been updated to use automake/autoconf/... throughout. so if builds fail, please tell me :-) i also factored out the image loading/saving code into plugins; this means that the Gem-core now has a very reduced set of dependencies and new image loading/saving modules can be easily added. i also hope it is a step towards making Gem compile on OSX-10.6 (reducing the immediate dependencies on QuickTime) the drawback is obviously, that you now need the image plugins live besides Gem as well (just like for the film/video/record stuff) on the long run, i would like to have (almost) everything platform dependent factored out of the Gem-core. fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3vuw4ACgkQkX2Xpv6ydvTm4ACfc3g9ffnfDQNV0ptf1+9EReh+ +NgAoOZ+6ZbvwnlmFpkBroLt6BGUZnUm =4OTO -----END PGP SIGNATURE-----

2 1

[ pd-gem-Bugs-3313799 ] example 04.pix/26.framebuffer_readback crash
by SourceForge.net 08 Jun '11

08 Jun '11

Bugs item #3313799, was opened at 2011-06-08 14:38 Message generated for change (Settings changed) made by nusmuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&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: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: example 04.pix/26.framebuffer_readback crash Initial Comment: the example 04.pix/26.framebuffer_readback crash pd with a segfault when creating the openGL windows this is with curent svn (rev 3971), ubuntu 10.04 I can see 2 different problem : - pix_snap does not create an image (pix_info after pix_snap gives only -1) - pix_buffer_read crash when reading this image ---------------------------------------------------------------------- >Comment By: Cyrille Henry (nusmuk) Date: 2011-06-08 20:04 Message: yes, you are right : pix_kaleidoscope crash here. if i remove it from the help patch, everything is now working as expected. (Gem revision 4025) that was not my experience with rev 3971. well... few hours, 54 revision latter, and this bug disappear. thanks ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 19:21 Message: on further inspection, i can reproduce a crash if i do X-forwarding to the amd64 machine (from a similar _32bit_ machine) a backtrace however still points to [pix_kaleidoscope] to be the culprit. could you run everything through gdb? ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 19:21 Message: could you provide a backtrace of the crash? on linux/osx/similar you can use gdb for producing one: $ gdb -args /path/to/pd -lib Gem -open /my/faulty/patch.pd [...] (gdb) run [... do something to trigger the crasher bug ...] (gdb) backtrace [...] ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 19:19 Message: hmm, checked on an debian/sid machine with 2.6.38-2-amd64 and nvidia-270.41.19 (and a fresh checkout of Gem) and still cannot reproduce. i noticed that [pix_kaleidoscope] does not work _correctly_ on amd64 though, but if i turn that off, everything works as expected. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-06-08 18:44 Message: nvidia driver intel i7 kernel 2.6.32 / 64 bit pix_snap does not work for framebuffer, but pix_write is working... ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 18:01 Message: weird; i'm unable to reproduce the problem. which drivers? which architecture? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…

1 0

[ pd-gem-Bugs-3313799 ] example 04.pix/26.framebuffer_readback crash
by SourceForge.net 08 Jun '11

08 Jun '11

Bugs item #3313799, was opened at 2011-06-08 16:38 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&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: Open Resolution: None Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: example 04.pix/26.framebuffer_readback crash Initial Comment: the example 04.pix/26.framebuffer_readback crash pd with a segfault when creating the openGL windows this is with curent svn (rev 3971), ubuntu 10.04 I can see 2 different problem : - pix_snap does not create an image (pix_info after pix_snap gives only -1) - pix_buffer_read crash when reading this image ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 21:21 Message: on further inspection, i can reproduce a crash if i do X-forwarding to the amd64 machine (from a similar _32bit_ machine) a backtrace however still points to [pix_kaleidoscope] to be the culprit. could you run everything through gdb? ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 21:21 Message: could you provide a backtrace of the crash? on linux/osx/similar you can use gdb for producing one: $ gdb -args /path/to/pd -lib Gem -open /my/faulty/patch.pd [...] (gdb) run [... do something to trigger the crasher bug ...] (gdb) backtrace [...] ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 21:19 Message: hmm, checked on an debian/sid machine with 2.6.38-2-amd64 and nvidia-270.41.19 (and a fresh checkout of Gem) and still cannot reproduce. i noticed that [pix_kaleidoscope] does not work _correctly_ on amd64 though, but if i turn that off, everything works as expected. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-06-08 20:44 Message: nvidia driver intel i7 kernel 2.6.32 / 64 bit pix_snap does not work for framebuffer, but pix_write is working... ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 20:01 Message: weird; i'm unable to reproduce the problem. which drivers? which architecture? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…

1 0

[ pd-gem-Bugs-3313799 ] example 04.pix/26.framebuffer_readback crash
by SourceForge.net 08 Jun '11

08 Jun '11

Bugs item #3313799, was opened at 2011-06-08 16:38 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&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: Open Resolution: None Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: example 04.pix/26.framebuffer_readback crash Initial Comment: the example 04.pix/26.framebuffer_readback crash pd with a segfault when creating the openGL windows this is with curent svn (rev 3971), ubuntu 10.04 I can see 2 different problem : - pix_snap does not create an image (pix_info after pix_snap gives only -1) - pix_buffer_read crash when reading this image ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 21:19 Message: hmm, checked on an debian/sid machine with 2.6.38-2-amd64 and nvidia-270.41.19 (and a fresh checkout of Gem) and still cannot reproduce. i noticed that [pix_kaleidoscope] does not work _correctly_ on amd64 though, but if i turn that off, everything works as expected. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-06-08 20:44 Message: nvidia driver intel i7 kernel 2.6.32 / 64 bit pix_snap does not work for framebuffer, but pix_write is working... ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 20:01 Message: weird; i'm unable to reproduce the problem. which drivers? which architecture? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…

1 0

[ pd-gem-Bugs-3313799 ] example 04.pix/26.framebuffer_readback crash
by SourceForge.net 08 Jun '11

08 Jun '11

Bugs item #3313799, was opened at 2011-06-08 14:38 Message generated for change (Comment added) made by nusmuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&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: Open Resolution: None Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: example 04.pix/26.framebuffer_readback crash Initial Comment: the example 04.pix/26.framebuffer_readback crash pd with a segfault when creating the openGL windows this is with curent svn (rev 3971), ubuntu 10.04 I can see 2 different problem : - pix_snap does not create an image (pix_info after pix_snap gives only -1) - pix_buffer_read crash when reading this image ---------------------------------------------------------------------- >Comment By: Cyrille Henry (nusmuk) Date: 2011-06-08 18:44 Message: nvidia driver intel i7 kernel 2.6.32 / 64 bit pix_snap does not work for framebuffer, but pix_write is working... ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-06-08 18:01 Message: weird; i'm unable to reproduce the problem. which drivers? which architecture? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…

1 0

[ pd-gem-Bugs-3313799 ] example 04.pix/26.framebuffer_readback crash
by SourceForge.net 08 Jun '11

08 Jun '11

1 0

[ pd-gem-Bugs-3313799 ] example 04.pix/26.framebuffer_readback crash
by SourceForge.net 08 Jun '11

08 Jun '11

Bugs item #3313799, was opened at 2011-06-08 14:38 Message generated for change (Tracker Item Submitted) made by nusmuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&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: Open Resolution: None Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: example 04.pix/26.framebuffer_readback crash Initial Comment: the example 04.pix/26.framebuffer_readback crash pd with a segfault when creating the openGL windows this is with curent svn (rev 3971), ubuntu 10.04 I can see 2 different problem : - pix_snap does not create an image (pix_info after pix_snap gives only -1) - pix_buffer_read crash when reading this image ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…

1 0

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

08 Jun '11

Bugs item #3308535, was opened at 2011-05-27 21:50 Message generated for change (Comment added) made by katjav 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: Open Resolution: None 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: Katja (katjav) Date: 2011-06-08 13: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 22: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-Feature Requests-3311982 ] mesh_square, cuve3d accept different messages
by SourceForge.net 05 Jun '11

05 Jun '11

Feature Requests item #3311982, was opened at 2011-06-05 17:41 Message generated for change (Comment added) made by nusmuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3311982&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: openGL Group: None Status: Open Priority: 5 Private: No Submitted By: max (maxn) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: mesh_square, cuve3d accept different messages Initial Comment: curve3d accepts draw fill, line, point, line1, line2, line3 line4 messages while mesh_square accepts draw default, line and point but no mesh (fill) at all though the name suggests that a mesh looks like a mesh. it would be nice if mesh_square could have a mesh and those commands would be better standardized. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-06-05 18:50 Message: I agree that curve3d draw message name are poorly chosen. and I also agree that mesh_square is missing some draw messages. I think we need some brain storming to choose good label for curve3d draw messages, and then use the same message for mesh_square. since I code both objects, I don't have any better suggestion for this messages. but i can code them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3311982&group_…

1 0

[ pd-gem-Feature Requests-3311982 ] mesh_square, cuve3d accept different messages
by SourceForge.net 05 Jun '11

05 Jun '11

Feature Requests item #3311982, was opened at 2011-06-05 17:41 Message generated for change (Tracker Item Submitted) made by maxn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3311982&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: openGL Group: None Status: Open Priority: 5 Private: No Submitted By: max (maxn) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: mesh_square, cuve3d accept different messages Initial Comment: curve3d accepts draw fill, line, point, line1, line2, line3 line4 messages while mesh_square accepts draw default, line and point but no mesh (fill) at all though the name suggests that a mesh looks like a mesh. it would be nice if mesh_square could have a mesh and those commands would be better standardized. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3311982&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 June 2011