[PD] buffer overflow with pix_image

[chris clepper]

Is there a system log item about killing the loginwindow process or anything
related abnormally?

On 9/14/06, user @ earweego <pd at 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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20060914/3d70f301/attachment.htm>