GEM-dev April 2011

gem-dev@lists.iem.at

9 participants
62 discussions

[ pd-gem-Bugs-3177361 ] no images with FW camera
by SourceForge.net 26 Apr '11

26 Apr '11

Bugs item #3177361, was opened at 2011-02-10 15:02 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3177361&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: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Cyrille Henry (nusmuk) Assigned to: Nobody/Anonymous (nobody) Summary: no images with FW camera Initial Comment: hello, with Gem svn, ubuntu 10.04 (kernell 2.6.32), and a guppy pro (from AVT) connected with FW800, i can't have images. (same result with a stingray from AVT) the camera create a device /dev/raw1394 and /dev/video1394/0 i've got video plugin dv4l and dc1394. coriender can grab images without any problem. i don't know if it's related, but when creating pix_video object, i've got an error in the terminal : libdc1394 error: Error: Failed to allocate iso bandwidth libdc1394 error: Error: Failed to setup DMA capture ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-26 12:31 Message: i added some "properties" to dc1394, which should allow you to set the operation mode and the iso-speed from within the patch. since i cannot find a dc1394 camera, please test whether this fixesyour problem. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-02-11 12:25 Message: ok, i find the solution. adding : dc1394_video_set_operation_mode(m_dccamera,DC1394_OPERATION_MODE_1394B); before setting speed to 800 solve the problem. so i've go an image. i don't know to make this to work with both FW400 and FW800 device... i still have a small problem : the device is not properly closed. after quitting pd, i have to unpluged it if i want to use it again. (the green led is blinking after closing pd, just like when grabbing is on). ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-02-11 11:56 Message: if i change line 269 of file videoDC1394.cpp from dc1394speed_t speed=DC1394_ISO_SPEED_400; to dc1394speed_t speed=DC1394_ISO_SPEED_800; iv've got more information about why this speed can't be allocated in the terminal : libdc1394 error: An ISO speed >400Mbps was requested while the camera is in LEGACY mode. Please set the operation mode to OPERATION_MODE_1394B before asking for 1394b ISO speeds libdc1394 error: Error: Failed to allocate iso bandwidth libdc1394 error: Error: Failed to setup DMA capture i just don't know how to do that. any help is apreciated in order to make this work for this camera. ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-02-10 16:08 Message: well, i did not have other cam connected when i tried this, so pix_video tried all backend at the initialization. so, i now have a v4l device on the computer. when creating pix_video : no messages regarding 1394. (only a message that say pix_video open a v4l2 device). sending driver dc1394 gives in the terminal : libdc1394 error: Error: Failed to allocate iso bandwidth libdc1394 error: Error: Failed to setup DMA capture and in pd log : error videoDC1394: Generic failure: failed to enumerate then, sending device /dev/raw1394 did not change anything. if i do the other order : recreate pix_video, sending device /dev/raw1394, i've got an error that say V4L can not open this device. then sending driver dc1394 print nothing. the camera is in FW800, the computer have only a FW800 port... ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-02-10 15:15 Message: this happens as soon as you create the [pix_video] object? Gem tries to set the bandwidth to 400 when it _open_s the device, but should fall back to whatever the device gives, if FW400 is not supported. but if the problem already occurs when creating [pix_video] (that is: when initializing the dc1394 infrastructure), it will never reach that... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3177361&group_…

1 0

[ pd-gem-Bugs-3292406 ] pix_snap help patch
by SourceForge.net 26 Apr '11

26 Apr '11

Bugs item #3292406, was opened at 2011-04-24 12:56 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&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: any operating system >Status: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_snap help patch Initial Comment: According to pix_snap's help patch, one would expect that all you need to have pix_snap take a snapshot is to send it a "snap" message at an arbitrary moment, but that won't work. The only way it works, is to send it the snap message just before the gemlist (0 ligical time before), i.e. with a [t a b]. This should definitely be mentioned in the help patch. The current help patch gives no clue that the attached example test_snap.pd won't work and that in order to make it work you need to do like shown in attached test_snap_2.pd The attached file snap_bare_minimum.pd shows the bare minimum (i think) which is needed to succesfully take a snapshot and I think something like this should be shown in the help patch. By the way it would also be worth mentioning that a bang works as a synonim of "snap", though many will guess that. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-26 12:28 Message: thanks for the report; i changed the help-patch to be very similar to the [pix_snap2tex] patch, which mentions, that you need something drawn to the framebuffer in order to be happy. this also makes for a more interactive experience :-) ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-24 15:34 Message: When reporting a bug, you did imply that things doesn't work. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2011-04-24 15:25 Message: That's what I meant, that the help patch misses a lot of information. I didn't mean to imply that pix_snap doesn't work as it should. I am not very good with documentation prose so I don't think I can provide an improved help patch; however I guess the scheme in the attached snap_bare_minimum.pd could be a starting point ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2011-04-24 14:13 Message: if you look at example 07.texture/07.feedback, you'll notice that pix_snap work if you use [t b a] (and not only [t a b])... if you send color 1 0 0 to the gemwin of your "test_snap.pd", you'll notice that pix_snap does snap a red bufffer : it's because it's working. but when you send a snap message when Gem did not draw an image, the buffer is empty... That is certainly why the help patch says that pix_snap work best in single buffer mode (the buffer is not automatically clear). So, i think pix_snap is working perfectly, but the help patch is clearly missing lot's of information. please, fell free to make a nice help patch that could replace the current one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…

1 0

[ pd-gem-Bugs-3292406 ] pix_snap help patch
by SourceForge.net 26 Apr '11

26 Apr '11

Bugs item #3292406, was opened at 2011-04-24 12:56 Message generated for change (Tracker Item Submitted) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&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: any operating system Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_snap help patch Initial Comment: According to pix_snap's help patch, one would expect that all you need to have pix_snap take a snapshot is to send it a "snap" message at an arbitrary moment, but that won't work. The only way it works, is to send it the snap message just before the gemlist (0 ligical time before), i.e. with a [t a b]. This should definitely be mentioned in the help patch. The current help patch gives no clue that the attached example test_snap.pd won't work and that in order to make it work you need to do like shown in attached test_snap_2.pd The attached file snap_bare_minimum.pd shows the bare minimum (i think) which is needed to succesfully take a snapshot and I think something like this should be shown in the help patch. By the way it would also be worth mentioning that a bang works as a synonim of "snap", though many will guess that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…

1 0

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

23 Apr '11

Bugs item #3281206, was opened at 2011-04-08 23:07 Message generated for change (Comment added) made by sistisette 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: Open 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: Matteo Sisti Sette (sistisette) Date: 2011-04-23 17: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-09 00: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 23: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-3292038 ] pix_snap: what does "work best" mean
by SourceForge.net 23 Apr '11

23 Apr '11

Bugs item #3292038, was opened at 2011-04-23 17:33 Message generated for change (Tracker Item Submitted) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292038&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: any operating system Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_snap: what does "work best" mean Initial Comment: The help patch for pix_snap says: "pix_snap works best with single buffered windows". What does it mean? What are exactly its limitations or known issues with double buffered windows? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292038&group_…

1 0

[ pd-gem-Bugs-3290926 ] Fails to build with 2.6.38 kernel
by SourceForge.net 21 Apr '11

21 Apr '11

Bugs item #3290926, was opened at 2011-04-21 14:31 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3290926&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: linux >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: amoog () Assigned to: Nobody/Anonymous (nobody) Summary: Fails to build with 2.6.38 kernel Initial Comment: The linux kernel 2.6.38 removed support for v4l1, causing a builderror: In file included from pix_video.cpp:18:0: ../Pixes/videoV4L.h:43:29: fatal error: linux/videodev.h: No such file or directory ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-04-21 15:20 Message: this is fixed in current SVN (for 0.93) if you need to run on 0.92, apply the patch as found here: http://git.debian.org/?p=collab-maint/gem.git;a=commitdiff;h=3ca23072692841… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3290926&group_…

1 0

[ pd-gem-Bugs-3290926 ] Fails to build with 2.6.38 kernel
by SourceForge.net 21 Apr '11

21 Apr '11

Bugs item #3290926, was opened at 2011-04-21 12:31 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3290926&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: linux Status: Open Resolution: None Priority: 5 Private: No Submitted By: amoog () Assigned to: Nobody/Anonymous (nobody) Summary: Fails to build with 2.6.38 kernel Initial Comment: The linux kernel 2.6.38 removed support for v4l1, causing a builderror: In file included from pix_video.cpp:18:0: ../Pixes/videoV4L.h:43:29: fatal error: linux/videodev.h: No such file or directory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3290926&group_…

1 0

[ pd-gem-Feature Requests-2880325 ] reduce interclass dependencies
by SourceForge.net 21 Apr '11

21 Apr '11

Feature Requests item #2880325, was opened at 2009-10-16 07:01 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2880325&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: misc Group: None >Status: Closed Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: reduce interclass dependencies Initial Comment: to get a more stable ABI, it would be nice if implementation details could be hidden from the public APIs of classes. - use pimpl (http://chadaustin.me/cppinterface.html) - use symbol-keyed dictionaries (e.g. for accessing data in GemState) - ... ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-04-21 12:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-04-07 12:10 Message: i think we are kind of there. for performance reasons, the GemState dictionary uses integer-keys though ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=2880325&group_…

1 0

[ pd-gem-Feature Requests-3134537 ] arguments for pix_crop
by SourceForge.net 21 Apr '11

21 Apr '11

Feature Requests item #3134537, was opened at 2010-12-10 19:19 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3134537&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: image processing Group: None >Status: Closed Priority: 5 Private: No Submitted By: max (maxn) Assigned to: IOhannes m zmlnig (zmoelnig) Summary: arguments for pix_crop Initial Comment: please add arguments for pix_crop ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-04-21 12:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-04-07 12:08 Message: hmm, actually [pix_crop] has had arguments for a long time, though this was not documented in the help-patch. i've updated the help-patch (and clamped the defaults to 64x64+0+0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3134537&group_…

1 0

[ pd-gem-Bugs-3279243 ] multimodel performance issue
by SourceForge.net 21 Apr '11

21 Apr '11

Bugs item #3279243, was opened at 2011-04-07 11:08 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3279243&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: linux >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Pierre M. (r33p) Assigned to: Nobody/Anonymous (nobody) Summary: multimodel performance issue Initial Comment: multimodel performs good with gem stable release 0.92.3 but multimodel is performing bad, i.e a very big cpu usage, with latest gem sources (0.93 svn, 06/04/2011) gem compiled with pd vanilla 0.43 latest sources (git) on ubuntu 10.10 64bits : 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011 x86_64 GNU/Linux see this files for test patch and models (.obj) files : http://92.243.12.140/610___Pd_Patches/Gem_Multimodel_TestPatch.tar.gz ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-04-21 12:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2011-04-07 11:52 Message: thanks for the report and the example; it turns out that the entire displaylists were rebuilt each time a new model was selected, which ate all the performance... should be fixed with rev3907 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3279243&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 April 2011