yes, with pix_film too... (I load .jpg files into it)<br>(and with pix_buffer too)<br><br>but maybe I'm wrong somewhere?<br>I join patchs with pix_buffer and pix_film...<br>(maybe you have to change file path to make it work)<br>
<br> is gem 0.91.3 the hottest Gem ?<br><br><br>thx.<br>stéfan<br><br><br><br><div class="gmail_quote">2009/4/27 chris clepper <span dir="ltr"><<a href="mailto:cgclepper@gmail.com">cgclepper@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Mon, Apr 27, 2009 at 6:27 AM, IOhannes m zmoelnig <span dir="ltr"><<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br></div>
first of all, this bug in Gem has been fixed in recent SVN (after your initial bug-report)<br>
the obvious solution is to run the hottest Gem (no release out, though; so you have to compile it yerself)<br>
<br>
and since it is (was) a bug in the implementation of Gem, there is no way you can "fix" it in Pd. the only workaround is to restart Pd (which will free all stray memory). "unloading" does not work, because the memory had been lost.</blockquote>
</div><div><br>Is this also bug with pix_film? I used pix_film for permanent installations to load hundreds of thousands of films over years without running into this problem. The same patch also had large pix_buffer objects that are stable in RAM usage.<br>
</div></div><br>
</blockquote></div><br>