thanks, folks!
so you say that pix_film is a pretty substitute for pix_image. I dont feel like trying and put all 500 images into a .mov, as they're all different dimensions and I guess that would not end up nicely. I'll try the pix_film thing!
about the crash report: the _weird_ thing is that there is none! Pd and pd just vanish so discretely during the nightly tests that I get back in the morning and there is not the slightest trace left that they were ever on... no MAC notification, no crash log,... hmmm. im now tryin to send some OSC messages to SC where I can log them and at least get an idea about how long it run before crashing.
curoius about this night;) bests, .hh.
chris wrote
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:
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 _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Is there a system log item about killing the loginwindow process or anything related abnormally?
On 9/14/06, user @ earweego pd@earweego.net wrote:
thanks, folks!
so you say that pix_film is a pretty substitute for pix_image. I dont feel like trying and put all 500 images into a .mov, as they're all different dimensions and I guess that would not end up nicely. I'll try the pix_film thing!
about the crash report: the _weird_ thing is that there is none! Pd and pd just vanish so discretely during the nightly tests that I get back in the morning and there is not the slightest trace left that they were ever on... no MAC notification, no crash log,... hmmm. im now tryin to send some OSC messages to SC where I can log them and at least get an idea about how long it run before crashing.
curoius about this night;) bests, .hh.
chris wrote
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:
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 _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
chris clepper -
user ＠ earweego