hello list,
for an installation in ZKM, we are using a GEM-based patch where a dozen of cubes are textured via [pix_image] with jpg-images of 35kB on avg. each cube changes its image about once per second, and we are getting heavy crashes after less than an hour.
using a MAC Dual G5 with OS X 10.4.4, 1.25GB RAM and PD version pd++_0_39_1 by James Tittle which is amazing for the rest - even fixed the tedious titlebar issue :)
apparently, the image buffer is not cleared after the new image was loaded, and thus the RAM is overflowing. We could work around this problem by changing the images less often, but it feels dirty as it would just _delay_ the crash to a time beyond exhibition duration. Would it help if the images had smaller pixel sizes and thus take less memory? I guess the bug is known, but is anybody able to fix it before the opening in one week ?
any hint would be greatly appreciated, bests, .hh.
I had some recent problems of a similar nature, using pix_multiimage - ie. memory is never freed but just keeps increasing as new images are loaded. I was advised to try converting the images into a single video, and playing the video instead. The way I do it, is to let the video play linearly into a buffer, and actually output the buffer into [pix-texture], but this is a workaround, because in the newer Gem, nonlinear playing doesn't seem to be working yet for WinXP...
However, with my approach, I'm not sure how to line up the frame rate of the video, with a metro + counter that sends images into the buffer. Since I do glitchy stuff, it's not important, but for you it might be.
~David
On 9/13/06, user @ earweego pd@earweego.net wrote:
hello list,
for an installation in ZKM, we are using a GEM-based patch where a dozen of cubes are textured via [pix_image] with jpg-images of 35kB on avg. each cube changes its image about once per second, and we are getting heavy crashes after less than an hour.
using a MAC Dual G5 with OS X 10.4.4, 1.25GB RAM and PD version pd++_0_39_1 by James Tittle which is amazing for the rest - even fixed the tedious titlebar issue :)
apparently, the image buffer is not cleared after the new image was loaded, and thus the RAM is overflowing. We could work around this problem by changing the images less often, but it feels dirty as it would just _delay_ the crash to a time beyond exhibition duration. Would it help if the images had smaller pixel sizes and thus take less memory? I guess the bug is known, but is anybody able to fix it before the opening in one week ?
any hint would be greatly appreciated, bests, .hh.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can use pix_film to load images on the Mac. That has proven stable for months on end of loading movies and should be similar for still images. You could also put the stills into a single movie file using Quicktime Pro or an Applescript.
On 9/13/06, user @ earweego pd@earweego.net wrote:
hello list,
for an installation in ZKM, we are using a GEM-based patch where a dozen of cubes are textured via [pix_image] with jpg-images of 35kB on avg. each cube changes its image about once per second, and we are getting heavy crashes after less than an hour.
using a MAC Dual G5 with OS X 10.4.4, 1.25GB RAM and PD version pd++_0_39_1 by James Tittle which is amazing for the rest - even fixed the tedious titlebar issue :)
apparently, the image buffer is not cleared after the new image was loaded, and thus the RAM is overflowing. We could work around this problem by changing the images less often, but it feels dirty as it would just _delay_ the crash to a time beyond exhibition duration. Would it help if the images had smaller pixel sizes and thus take less memory? I guess the bug is known, but is anybody able to fix it before the opening in one week ?
any hint would be greatly appreciated, bests, .hh.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
A crash log would be nice to have. ~/Library/Logs/CrashReporter
Running out of RAM should not cause a crash but rather a slowdown.
On 9/13/06, user @ earweego pd@earweego.net wrote:
hello list,
for an installation in ZKM, we are using a GEM-based patch where a dozen of cubes are textured via [pix_image] with jpg-images of 35kB on avg. each cube changes its image about once per second, and we are getting heavy crashes after less than an hour.
using a MAC Dual G5 with OS X 10.4.4, 1.25GB RAM and PD version pd++_0_39_1 by James Tittle which is amazing for the rest - even fixed the tedious titlebar issue :)
apparently, the image buffer is not cleared after the new image was loaded, and thus the RAM is overflowing. We could work around this problem by changing the images less often, but it feels dirty as it would just _delay_ the crash to a time beyond exhibition duration. Would it help if the images had smaller pixel sizes and thus take less memory? I guess the bug is known, but is anybody able to fix it before the opening in one week ?
any hint would be greatly appreciated, bests, .hh.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
user @ earweego wrote:
hello list,
for an installation in ZKM, we are using a GEM-based patch where a dozen of cubes are textured via [pix_image] with jpg-images of 35kB on avg. each cube changes its image about once per second, and we are getting heavy crashes after less than an hour.
if they occur that often, could you try to do a backtrace with gdb?
like (in the console): ~> gdb /path/to/pd/binary/pd (gdb) run -lib Gem -lib otherlibs -path /all/paths/ -open patch.pd ... ... ...CRASH! (gdb) bt
using a MAC Dual G5 with OS X 10.4.4, 1.25GB RAM and PD version pd++_0_39_1 by James Tittle which is amazing for the rest - even fixed the tedious titlebar issue :)
which version of Gem? self-compiled??
mfga.dsr IOhannes
-
chris clepper -
David Powers -
IOhannes m zmoelnig -
user ＠ earweego