GEM-dev May 2010

gem-dev@lists.iem.at

9 participants
45 discussions

[ pd-gem-Bugs-3007370 ] pix_dump does not properly after an image has been resized
by SourceForge.net 26 May '10

26 May '10

Bugs item #3007370, was opened at 2010-05-26 15:53 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007370&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: Thomas O Fredericks (mrtof) Assigned to: Nobody/Anonymous (nobody) Summary: pix_dump does not properly after an image has been resized Initial Comment: pix_dump does not dump the pixel data properly of a greyscale video feed that has been resized to 25x25 pixels: 1) The number of pixels returned is 624 instead of 625! 2) If the dumped data is fed back to a pix_set the resulting image is garbage Note: I want to resize the video to such a low resolution to send the pixel data by serial to a Peggy 2. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-26 18:07 Message: [pix_dump] in greyscale mode currently needs the number of pixels be dividible by 4. so if you can live with a 24*24 or a 26*26 image, you will be on the save side. anyhow, the issue only skips the remaining pixels, so adding dummy-pixels manually could help... i committed a fix to svn/trunk with revision #3357 i committed a fix to svn/branches/0.92 with revision #3359 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007370&group_…

1 0

[ pd-gem-Bugs-3007370 ] pix_dump does not properly after an image has been resized
by SourceForge.net 26 May '10

26 May '10

Bugs item #3007370, was opened at 2010-05-26 15:53 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007370&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: Thomas O Fredericks (mrtof) Assigned to: Nobody/Anonymous (nobody) Summary: pix_dump does not properly after an image has been resized Initial Comment: pix_dump does not dump the pixel data properly of a greyscale video feed that has been resized to 25x25 pixels: 1) The number of pixels returned is 624 instead of 625! 2) If the dumped data is fed back to a pix_set the resulting image is garbage Note: I want to resize the video to such a low resolution to send the pixel data by serial to a Peggy 2. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-26 18:07 Message: [pix_dump] in greyscale mode currently needs the number of pixels be dividible by 4. so if you can live with a 24*24 or a 26*26 image, you will be on the save side. anyhow, the issue only skips the remaining pixels, so adding dummy-pixels manually could help... i committed a fix to svn/trunk with revision #3357 i committed a fix to svn/branches/0.92 with revision #3359 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007370&group_…

1 0

[ pd-gem-Bugs-3007373 ] pix_resize crashes PD if a dimension is set before rendering
by SourceForge.net 26 May '10

26 May '10

Bugs item #3007373, was opened at 2010-05-26 15:59 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007373&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Thomas O Fredericks (mrtof) Assigned to: Nobody/Anonymous (nobody) Summary: pix_resize crashes PD if a dimension is set before rendering Initial Comment: pix_resize crashes PD once the gemwin is created if a "dimen 25 25" was sent to the object before the gemwin was created. This also happens if the dimensions are set as arguments. ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-26 17:00 Message: unable to reproduce i tried with both Gem-0.92 (svn/branches/0.92) and svn/trunk an there ar no crashes. please provide detailed information about your system (versions!) and a simple example patch that triggers the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007373&group_…

1 0

[ pd-gem-Bugs-3007373 ] pix_resize crashes PD if a dimension is set before rendering
by SourceForge.net 26 May '10

26 May '10

Bugs item #3007373, was opened at 2010-05-26 09:59 Message generated for change (Tracker Item Submitted) made by mrtof You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007373&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: 5 Private: No Submitted By: Thomas O Fredericks (mrtof) Assigned to: Nobody/Anonymous (nobody) Summary: pix_resize crashes PD if a dimension is set before rendering Initial Comment: pix_resize crashes PD once the gemwin is created if a "dimen 25 25" was sent to the object before the gemwin was created. This also happens if the dimensions are set as arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007373&group_…

1 0

[ pd-gem-Bugs-3007370 ] pix_dump does not properly after an image has been resized
by SourceForge.net 26 May '10

26 May '10

Bugs item #3007370, was opened at 2010-05-26 09:53 Message generated for change (Tracker Item Submitted) made by mrtof You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007370&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: 5 Private: No Submitted By: Thomas O Fredericks (mrtof) Assigned to: Nobody/Anonymous (nobody) Summary: pix_dump does not properly after an image has been resized Initial Comment: pix_dump does not dump the pixel data properly of a greyscale video feed that has been resized to 25x25 pixels: 1) The number of pixels returned is 624 instead of 625! 2) If the dumped data is fed back to a pix_set the resulting image is garbage Note: I want to resize the video to such a low resolution to send the pixel data by serial to a Peggy 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3007370&group_…

1 0

[ pd-gem-Bugs-2972166 ] pix_crop, pix_resize don't "refresh" when they should
by SourceForge.net 22 May '10

22 May '10

Bugs item #2972166, was opened at 2010-03-17 20:12 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972166&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: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: pix_crop, pix_resize don't "refresh" when they should Initial Comment: If you use a pix_crop on a pix_film: [pix_film] | [pix_crop] when [pix_film] has auto off, if you send floats into any of [pix_crop]'s inlets, the texture won't change accordingly until you move to another frame in [pix_film] (i.e. send a number to its right inlet or enable auto mode) I don't know whether this is an issue with pix_film or pix_crop. This does not happen with [pix_image] in conjunction with pix_crop, so it's probably pix_film. Then [pix_resize] has a similar issue: if you have: [pix_film] | [pix_resize] OR [pix_image] | [pix_resize] when you send a [dimen( message to pix_resize to change the target size, it won't change until the input pix changes. In the case of pix_film it won't change until the frame changes; in the case of pix_image it won't change until you load another image!!!!!!! This seems somewhat similar to what happens with [pix_crop], however in this case it does apply to [pix_image] too, so it would suggest an issue in [pix_resize] rather than [pix_film] or [pix_image]. I haven't done intensive testing, so it may apply to more pix objects. I don't even know if the problem may be in [pix_texture]. I attach a simple test patch for convenience. You'll need a myimage.jpg image file and a myvideo.mov movie file. And now a nastier thing, possibly related: 1) Open the attached patch, create the gemwin and click on the open messages to [pix_film]s You see the four images, twice the image and twice the video 2) Disconnect the upper [pix_image] and [pix_film] objects both from their input and output 3) move the [pix_film] on the right to the render chain on the left and connect it You would expect the video to appear but no: the jpeg image reappears, though the [pix_image] is even disconnected!!!! This is probably the same bug described above. Try all the viceversa's ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-05-22 02: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: 2010-05-07 10:43 Message: we believe that this has been fixed in svn/trunk with commits r3262, r3263 and r3264 ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-07 08:51 Message: you can use [pix_separator] to workarund. fgmasdr IOhannes ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2010-03-17 22:18 Message: With pix_film, if you have to change a crop or resize of the image while not changing the frame, even sending the same frame number again won't work: the cropped or resized image won't be refreshed until pix_film actually goes to a different frame. So it is not "workaroundable" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972166&group_…

1 0

[ pd-gem-Bugs-2979943 ] [triangle] is not equilateral as its help claims
by SourceForge.net 22 May '10

22 May '10

Bugs item #2979943, was opened at 2010-03-31 11:35 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2979943&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: Accepted Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: [triangle] is not equilateral as its help claims Initial Comment: If [triangle] were an equilateral triangle as the help patch claims it is, 6 rotated-and-translated copies could form a hexagon with no gaps or overlaps. However, if you try this, the hexagon has gaps: I suspect the triangle is an isoceles triangle with base 1 and height 1, instead of equilateral with sides all 1. I also suspect too many patches will depend on the current shape of [triangle], so please correct the help to say what it actually is. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-05-22 02: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: 2010-05-07 08:49 Message: i totally agree you arre right with your assumption on the triangle changed in trunk with revision 3261. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2979943&group_…

1 0

[ pd-gem-Bugs-2972644 ] rectangular textures default is platform-dependent
by SourceForge.net 22 May '10

22 May '10

Bugs item #2972644, was opened at 2010-03-18 15:28 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972644&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: Wont Fix Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: rectangular textures default is platform-dependent Initial Comment: [pix_texture] has rectangle mode ON by default on Mac, and OFF by default on Windows. I don't know on Linux. The default should obviously be the same on all platforms, no matter which one. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-05-22 02: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: 2010-05-07 08:34 Message: they are different because of performance reasons. so this is actually a feature, not a bug. and yes, upcoming versions of Gem will allow you to set your personal default to whatever pleases you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972644&group_…

1 0

[ pd-gem-Bugs-2997533 ] part_render crash when speed is set high
by SourceForge.net 22 May '10

22 May '10

Bugs item #2997533, was opened at 2010-05-06 10:28 Message generated for change (Settings changed) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2997533&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: linux >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: zomoipotoi (zomoipotoi) Assigned to: Nobody/Anonymous (nobody) Summary: part_render crash when speed is set high Initial Comment: I have a particle system with part_head with no arguments (defaults to 1000 particles max). I use part_render and start rendering. Then I set part_head's speed to eg. 300, then my pd crash. My system is: PD 0.42.5 - GEM 0.92.2 - Ubuntu 9.04 64 bit - NVIDIA GTX 260 ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-05-22 02: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: Nobody/Anonymous (nobody) Date: 2010-05-07 08:50 Message: ok, tested again and no more crashes. for the flags stripped... ok, now I know what's the problem (sorry, sometimes I'm a noob). so thanks again. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-07 08:13 Message: cool that it works when downloading svn-snapshot via viewvc, all the executable flags are stripped away (i guess that's for safety reasons) ---------------------------------------------------------------------- Comment By: zomoipotoi (zomoipotoi) Date: 2010-05-06 16:06 Message: sorry for the last comment... solved the autogen problem with "sh autogen.sh" I've compiled succesfully the source from http://pd-gem.svn.sourceforge.net/viewvc/pd-gem/branches/ After the first tests it's seems to be ok!!! Thanks a lot!!! for the patch and GEM develop!!! ciao, dario ---------------------------------------------------------------------- Comment By: zomoipotoi (zomoipotoi) Date: 2010-05-06 15:55 Message: I've substituted the two files (part_render.cpp and part_render.h) in my gem 0.92.2 folder. Then make give me the following error: part_render.cpp:17: error: stray # in program part_render.cpp:17:66: error: invalid suffix "px" on integer constant part_render.cpp:17: error: stray # in program part_render.cpp:17:95: error: invalid suffix "px" on integer constant part_render.cpp:17:158: error: exponent has no digits part_render.cpp:17:190: error: exponent has no digits part_render.cpp:27:23: warning: character constant too long for its type part_render.cpp:28:32: warning: character constant too long for its type part_render.cpp:29:39: error: empty character constant part_render.cpp:167:16: warning: character constant too long for its type part_render.cpp:167:126: warning: character constant too long for its type part_render.cpp:167:153: warning: unknown escape sequence '\/' part_render.cpp:167:153: warning: character constant too long for its type part_render.cpp:238: error: stray # in program part_render.cpp:240: error: stray # in program part_render.cpp:241: error: stray # in program part_render.cpp:243: error: stray # in program part_render.cpp:366:103: error: too many decimal points in number part_render.cpp:5: error: expected unqualified-id before < token part_render.cpp:17: error: expected constructor, destructor, or type conversion before . token part_render.cpp:17: error: expected constructor, destructor, or type conversion before . token part_render.cpp:17: error: expected unqualified-id before < token part_render.cpp:23: error: expected constructor, destructor, or type conversion before = token part_render.cpp:24: error: expected unqualified-id before < token part_render.cpp:28: error: var does not name a type part_render.cpp:29: error: var does not name a type part_render.cpp:30: error: expected unqualified-id before < token part_render.cpp:35: error: expected constructor, destructor, or type conversion before . token part_render.cpp:36: error: expected unqualified-id before < token part_render.cpp:66: error: expected unqualified-id before < token part_render.cpp:67: error: expected unqualified-id before < token part_render.cpp:68: error: SCM does not name a type part_render.cpp:74: error: expected constructor, destructor, or type conversion before - token part_render.cpp:87: error: expected constructor, destructor, or type conversion before < token part_render.cpp:94: error: expected unqualified-id before numeric constant part_render.cpp:107: error: expected constructor, destructor, or type conversion before < token part_render.cpp:117: error: expected constructor, destructor, or type conversion before < token part_render.cpp:127: error: expected constructor, destructor, or type conversion before < token part_render.cpp:134: error: expected constructor, destructor, or type conversion before . token part_render.cpp:168: error: expected constructor, destructor, or type conversion before ++ token part_render.cpp:170: error: expected unqualified-id before < token part_render.cpp:238: error: expected constructor, destructor, or type conversion before . token part_render.cpp:238: error: expected unqualified-id before < token part_render.cpp:240: error: expected constructor, destructor, or type conversion before . token part_render.cpp:240: error: expected unqualified-id before < token part_render.cpp:241: error: expected constructor, destructor, or type conversion before / token part_render.cpp:241: error: expected unqualified-id before < token part_render.cpp:243: error: expected constructor, destructor, or type conversion before . token part_render.cpp:243: error: expected unqualified-id before < token part_render.cpp:263: error: expected unqualified-id before < token part_render.cpp:270: error: expected unqualified-id before < token make[1]: *** [part_render.o] Errore 1 I'm miss something? PS: I'm trying to compile the sources downloaded from http://pd-gem.svn.sourceforge.net/viewvc/pd-gem/branches/ But I'm not able to start the compilation: when I run ~/pd/source/gem-0.92-2-part_render/src$ ./autogen the console tell me "Nessun file o directory" (No file or directory) No problem in the old 0.92-2 source. Don't know what to do now, sorry thanks, dario ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-06 15:16 Message: there was an obvious allocation problem, which i have no fixed in both trunk and branch/0.92 http://pd-gem.svn.sourceforge.net/viewvc/pd-gem?view=rev&revision=3260 could you try and tell whether this fixes the problem? ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-06 13:27 Message: thanks for the backtrace could you also provide a minimal patch triggering the crash? ---------------------------------------------------------------------- Comment By: zomoipotoi (zomoipotoi) Date: 2010-05-06 13:03 Message: Hi Iohannes, this is the gdb output when pd crashed: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fcb6c31b6f0 (LWP 16777)] pd_typedmess (x=0x3f8000003f800000, s=0x1ca5e60, argc=2, argv=0x7fff74341e90) at m_class.c:635 635 t_class *c = *x; this is the gdb backtrace: #0 pd_typedmess (x=0x3f8000003f800000, s=0x1ca5e60, argc=2, argv=0x7fff74341e90) at m_class.c:635 #1 0x0000000000469b9a in outlet_anything (x=<value optimized out>, s=0x1ca5e60, argc=2, argv=0x7fff74341e90) at m_obj.c:390 #2 0x00007fcb6a178105 in GemBase::continueRender () from /usr/local/lib/pd/extra/Gem.pd_linux #3 0x00007fcb6a20188d in part_render::render () from /usr/local/lib/pd/extra/Gem.pd_linux #4 0x00007fcb6a178163 in GemBase::gem_renderMess () from /usr/local/lib/pd/extra/Gem.pd_linux #5 0x000000000046703a in pd_typedmess (x=0x25fe200, s=0x1ca5e60, argc=2, argv=0x7fff74341e90) at m_class.c:681 #6 0x0000000000469b9a in outlet_anything (x=<value optimized out>, s=0x1ca5e60, argc=2, argv=0x7fff74341ff0) at m_obj.c:390 #7 0x00007fcb6a178105 in GemBase::continueRender () from /usr/local/lib/pd/extra/Gem.pd_linux #8 0x00007fcb6a17816e in GemBase::gem_renderMess () from /usr/local/lib/pd/extra/Gem.pd_linux #9 0x000000000046703a in pd_typedmess (x=0x2623c10, s=0x1ca5e60, argc=2, argv=0x7fff74341e90) at m_class.c:681 #10 0x0000000000469b9a in outlet_anything (x=<value optimized out>, s=0x1ca5e60, argc=2, argv=0x7fff743420f0) at m_obj.c:390 #11 0x00007fcb6a178105 in GemBase::continueRender () #12 0x00007fcb6a17816e in GemBase::gem_renderMess () from /usr/local/lib/pd/extra/Gem.pd_linux #13 0x000000000046703a in pd_typedmess (x=0x26239f0, s=0x1ca5e60, argc=2, argv=0x7fff74341e90) at m_class.c:681 #14 0x0000000000469b9a in outlet_anything (x=<value optimized out>, s=0x1ca5e60, argc=2, argv=0x7fff743421f0) at m_obj.c:390 #15 0x00007fcb6a178105 in GemBase::continueRender () from /usr/local/lib/pd/extra/Gem.pd_linux #16 0x00007fcb6a17816e in GemBase::gem_renderMess () from /usr/local/lib/pd/extra/Gem.pd_linux #17 0x000000000046703a in pd_typedmess (x=0x25fe080, s=0x1ca5e60, argc=2, argv=0x7fff74341e90) at m_class.c:681 #18 0x0000000000469b9a in outlet_anything (x=<value optimized out>, s=0x1ca5e60, argc=2, argv=0x7fff743422f0) at m_obj.c:390 #19 0x00007fcb6a178105 in GemBase::continueRender () from /usr/local/lib/pd/extra/Gem.pd_linux #20 0x00007fcb6a17816e in GemBase::gem_renderMess () from /usr/local/lib/pd/extra/Gem.pd_linux #21 0x000000000046703a in pd_typedmess (x=0x25ffe40, s=0x1ca5e60, argc=2, argv=0x7fff74341e90) at m_class.c:681 #22 0x0000000000469b9a in outlet_anything (x=<value optimized out>, s=0x1ca5e60, argc=2, argv=0x7fff743423f0) at m_obj.c:390 #23 0x00007fcb6a1c8f33 in gemhead::renderGL () from /usr/local/lib/pd/extra/Gem.pd_linux #24 0x00007fcb6a197e2b in GemMan::renderChain () from /usr/local/lib/pd/extra/Gem.pd_linux #25 0x00007fcb6a1983d4 in GemMan::render () from /usr/local/lib/pd/extra/Gem.pd_linux #26 0x0000000000474db6 in m_mainloop () at m_sched.c:372 #27 0x0000000000479fcd in sys_main (argc=<value optimized out>, argv=<value optimized out>) at s_main.c:313 #28 0x00007fcb6b3085a6 in __libc_start_main () from /lib/libc.so.6 #29 0x00000000004107f9 in _start () at ../sysdeps/x86_64/elf/start.S:113 Thanks a lot! dario ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-05-06 12:48 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: zomoipotoi (zomoipotoi) Date: 2010-05-06 10:33 Message: with -verbose flag the console says "Errore del bus" (italian) -> "Bus error" (I think this is the translation) when the crash occur ---------------------------------------------------------------------- Comment By: zomoipotoi (zomoipotoi) Date: 2010-05-06 10:30 Message: pd crash with Segmentation fault ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2997533&group_…

1 0

[pix_video]: how to free the device?
by Roman Haefeli 19 May '10

19 May '10

Hi all I couldn't find method to free a device, that is used by [pix_video]. Is it really missing or just not documented? The only way I could find to free a device, that was in use by [pix_video] was to shut down Pd. Is there a more elegant way? Roman

4 16

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev May 2010