GEM-dev December 2009

gem-dev@lists.iem.at

8 participants
16 discussions

[ pd-gem-Bugs-2909779 ] pix_data somtime crash when loading new image
by SourceForge.net 15 Dec '09

15 Dec '09

Bugs item #2909779, was opened at 2009-12-07 00:20 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2909779&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: pix_data somtime crash when loading new image Initial Comment: The crash could append : - if pix_image use thread - when sending a open message to pix_image - when the old and new image have different size - when pix_data coordinate are high (near 1). it did not append with every image size it did not crash everytime. attachement is a patch + images that make pd to segfault ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-12-14 11:44 Message: i believe this to be fixed with r3028 in TRUNK. backport for 0.92 is still pending till someone can confirm that it is really fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2909779&group_…

3 6

[ pd-gem-Bugs-2887417 ] missing QTCF.DLL
by SourceForge.net 13 Dec '09

13 Dec '09

Bugs item #2887417, was opened at 2009-10-27 19:46 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2887417&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: Works For Me Priority: 5 Private: No Submitted By: megalegoland (megalegoland) Assigned to: Nobody/Anonymous (nobody) Summary: missing QTCF.DLL Initial Comment: Hello, I had to put QTCF.dll in pd/bin for using Gem in last release of pd-extended, and then it gives this pretty message on the console: GEM: Graphics Environment for Multimedia GEM: ver: 0.91.3 'tigital' GEM: compiled: Jan 22 2009 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: James Tittle GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al. GEM: found a bug? miss a feature? please report it: GEM: homepage http://gem.iem.at/ GEM: bug-tracker http://sourceforge.net/projects/pd-gem/ GEM: mailing-list http://lists.puredata.info/listinfo/gem-dev/ GEM: compiled for SIMD architecture: SSE2 MMX GEM: using SSE2 optimization Gem Man: QT init OK instead of an orwellian error message automatically sent to bigswifty ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-13 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: 2009-11-28 16:05 Message: during a workshop i had some participant who had no QuickTime installed on their vista machines. (using PdX but the latest Gem release) everything worked as expected (just used the plain installer from http://gem.iem.at; QT could obviously be not used, but the rest worked) i suspect this to be a problem with the Gem that comes with PdX. please consider upgrading. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-10-27 20:49 Message: oh, and which version of windows are you using? did/do you have quicktime installed? if so, which version? ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-10-27 20:48 Message: what happened without the QTCF.dll? did Gem refuse to load (which it shouldn't) or did it only complain about no-quicktime-support (which it should) does the same pproblem persist if you use the gem-0.92 release found at http://gem.iem.at (or here at the sourceforge in the download section) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2887417&group_…

1 0

crazy bug: all user actions executed twice
by Matteo Sisti Sette 10 Dec '09

10 Dec '09

Hi, I write just to see if anybody has already seen this happaning and can give me some clue as how to avoid it. I am not even sure the problem is with GEM, but I have worked on much more huge patches in PD without gem and never seen anything similar. I am on Windows Vista with the latest PD Vanilla and the latest GEM. I have not been able to isolate the problem; if anybody with some possibility to debug it is willing to try the patch and find out something I can send it to him/her. So, the problem is, in some occasions, very frequently (usually after opening the main patch, closing it, and opening it again), every user action (e.g.: clicking on a bang or toggle, hitting some key INCLUDING ctrl+1 to create an object or introducing input into an object or message box, or even a "save as") gets executed two or even more times. As you can imagine that fucks everything up. If I just open the patch and run it it works fine, but for even the smallest change that implies modifying some abstraction, I have to close PD, open it again, modify the abstraction I have to modify, save, close PD and open it again, since if I just save or even if I close all patches and open the main one again, everything is fucked up. It is impossible to work this way. Usually restarting the computer makes the bug disappear but then it is a matter of minutes before it starts showing again. I know that, if this is the first time you hear of it, you will hardly be hable to help, but my hope is that someone has observed this already and have been able to link it to a particular object or condition. By the way, I have checked that when this happens, NO duplicate "pd.exe" nor "whish84" process exists (provided that task manager is reliable). Thanks in advance m. -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

2 1

snapshot misteries, bang to gemhead
by Matteo Sisti Sette 07 Dec '09

07 Dec '09

Hi, I'm working on a patch (not the attached one which is an example that isolates the problem), where from time to time I need to take a snapshot of the whole scene and "draw" it as a texture on a rectangle which is on the background. (when the patch is finished I think I will be allowed to share it, for what it's worth) I have it all working fine, but than I came into a problem: sometimes, I have to send a message to take the snapshot, and immediately after, send some other message that changes something on the scene, which has to happen AFTER the snapshot. Since I am taking snapshots in the "classic" way, that is, opening a spigot on the gemlist that comes to the [pix_snap], the snapshot is actually deferred until the next render; this is a problem because I need to "defer" any other message that has to take effet just after the sbapshot; this can be done but i'd like to avoid all the complications. I thought that a solution would be to force a render just after any snapshot, by sending a bang to the gemhead that is rendering everithing. However, the result is not what I expected and I really can't understand why. That's why I am asking for your help. So, the attached patch is a simplification, in which I draw an initially white square and a sphere. If you hit the big bang (sorry for the pun), a snapshot of the scene is taken via [pix_snap] and it becomes the texture of the square. You can use the number box to move the sphere around. Now, if I make the connection where it says "connect this", what I am doing is just provoking a bang to the gemhead just after opening the spigot to the pix_snap. What I would expect is that it should work exactly the same as before (with the difference that an extra frame is rendered between two "normal" frames, and that's the moment the snapshot is taken; but this difference should not be "visible"). However, the observed behaviour is not this. The snapshot that is taken and "printed" on the texture is not the scene, but some aberration of it. If you leave the sphere wher it is, it will usually render and snap an all-black scene; but if you move the sphere to the back, behind the square, the snapshot will take the sphere very near to the "eye"...... I really don't understand. Doesn't the bang to the gemhead provoke a full render of everything just the same as it is rendered when a new frame occurs? Then why is the scene rendered differently when I do the bang???? I guess this could be further isolated to something regarding the bang to gemhead, i.e. without involving pix_snap; of course with a "fast" enough to see what happens during a single extra frame.... Thanks in advance By the way, thanks to all who gave me example patches some days ago which have helped me building this patch. m. -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com #N canvas 702 93 635 593 12; #X obj 304 560 gemwin; #X msg 377 514 destroy; #X obj 192 96 gemhead; #X obj 192 131 t a a a; #X obj 460 217 separator; #X obj 461 336 square 3; #X obj 189 256 rotateXYZ 0 0 0; #X floatatom 347 67 5 0 0 0 - - -; #X obj 190 184 separator; #X obj 461 303 pix_texture; #X obj 43 260 separator; #X obj 198 400 color 1 0 0; #X obj 198 425 sphere 1; #X obj 198 368 translateXYZ 0 0 1; #X msg 272 487 dimen 400 400 \, create \, 1; #X obj 41 567 pix_snap 400 400; #X obj 32 34 bng 30 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 84 382 t b b; #X msg 81 427 1; #X obj 42 459 spigot; #X obj 41 496 t a b; #X msg 109 462 0; #X text 306 696 ========; #X obj 39 530 t a b; #X obj 41 611 pix_texture; #X obj 38 312 pix_separator; #X obj 460 246 pix_separator; #X obj 460 276 color 1 1 1; #X obj 186 220 pix_separator; #X obj 180 38 t b; #X text 199 74 <== connect this; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 3 0 10 0; #X connect 3 1 8 0; #X connect 3 2 4 0; #X connect 4 0 26 0; #X connect 6 0 13 0; #X connect 7 0 6 2; #X connect 8 0 28 0; #X connect 9 0 5 0; #X connect 10 0 25 0; #X connect 11 0 12 0; #X connect 13 0 11 0; #X connect 14 0 0 0; #X connect 15 0 24 0; #X connect 16 0 17 0; #X connect 17 0 29 0; #X connect 17 1 18 0; #X connect 18 0 19 1; #X connect 19 0 20 0; #X connect 20 0 23 0; #X connect 20 1 21 0; #X connect 21 0 19 1; #X connect 23 0 15 0; #X connect 23 1 15 0; #X connect 24 1 9 1; #X connect 25 0 19 0; #X connect 26 0 27 0; #X connect 27 0 9 0; #X connect 28 0 6 0;

2 5

[ pd-gem-Bugs-2909779 ] pix_data somtime crash when loading new image
by SourceForge.net 07 Dec '09

07 Dec '09

Bugs item #2909779, was opened at 2009-12-06 23:20 Message generated for change (Tracker Item Submitted) made by nusmuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2909779&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: pix_data somtime crash when loading new image Initial Comment: The crash could append : - if pix_image use thread - when sending a open message to pix_image - when the old and new image have different size - when pix_data coordinate are high (near 1). it did not append with every image size it did not crash everytime. attachement is a patch + images that make pd to segfault ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2909779&group_…

1 0

ARToolkit issue on 10.4/Intel
by Hans-Christoph Steiner 06 Dec '09

06 Dec '09

So I installed artoolkit from Fink, and Gem gives this build error, which is new to me. Is it worth trying to get artoolkit support into the 0.92 build in the current Pd-extended builds? g++ -o Gem.pd_darwin -dynamiclib -mmacosx-version-min=10.3 - undefined dynamic_lookup -framework QuickTime -framework Carbon - framework AGL -framework OpenGL ./Objects/*.o -lAR -L/sw/lib -L/sw/ lib -lstdc++ -ldl -lz -lm -lpthread -L/Users/pd/auto-build/pd- extended/pd/bin -L/sw/lib -Wl,-framework,OpenGL -Wl,- framework,CoreServices -Wl,-framework,ApplicationServices -lobjc - lfreetype -lz -lftgl -L/sw/lib -lgmerlin_avdec -lgavl ld: common symbols not allowed with MH_DYLIB output format with the - multi_module option /sw/lib/libAR.a(arUtil.o) definition of common _arParam (size 144) /sw/lib/libAR.a(arUtil.o) definition of common _arImXsize (size 16) /sw/lib/libAR.a(arUtil.o) definition of common _arImYsize (size 16) /sw/lib/libAR.a(arUtil.o) definition of common _arsMatR2L (size 96) /sw/lib/libAR.a(arUtil.o) definition of common _arsParam (size 368) /usr/libexec/gcc/i686-apple-darwin8/4.0.1/libtool: internal link edit command failed make[2]: *** [Gem.pd_darwin] Error 1 An Apple person recommends adding -fno-common to the build: http://gcc.gnu.org/ml/gcc/2005-06/msg00378.html Others recommend not using multi_module mode, and sending - single_module: http://lists.apple.com/archives/Unix-porting/2006/Aug/msg00024.html http://doc.trolltech.com/qt3/platforms/osx.html .hc ---------------------------------------------------------------------------- "[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev December 2009