Ben<br><br>I don't see how setting a max number to grow to is any different than allocating N number of frames to begin with. GEM only grabs memory when you put an image into a slot the first time or replace one with a different size.<br>
<br>So you can do [pix_buffer biggie 10000] and only use 500 frames with no penalty.<br><br>Chris<br><br><div class="gmail_quote">On Fri, Mar 12, 2010 at 5:12 PM, B. Bogart <span dir="ltr"><<a href="mailto:ben@ekran.org">ben@ekran.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hey all,<br>
<br>
I'm use pix_buffers to store non-sequential images based on index.<br>
<br>
I'd like to be able to grow a pix_buffer by 1 element at a time.<br>
<br>
[add < would add a single slot to the end of the buffer. Its index would be calculated from the length of the buffer.<br>
<br>
The object could initiated as a growing pix_buffer by using a 0 as the size argument.<br>
<br>
There could be an upper limit of how many slots the buffer could grow to. Or a second argument could define the max size, but then it would need to send a signal when the buffer reached max, so maybe keeping tracking of the size on the PD side would work better...<br>
<br>
Anyhow I'm just thinking aloud here.<br>
<br>
The only alternative I can think of is using a bunch of pix_buffers, each holding a single image, that get dynamically created. That is bound to be a lot less efficient, and certainly uglier than a central storage area.<br>
<br>
.b.<br>
<br>
_______________________________________________<br>
GEM-dev mailing list<br>
<a href="mailto:GEM-dev@iem.at" target="_blank">GEM-dev@iem.at</a><br>
<a href="http://lists.puredata.info/listinfo/gem-dev" target="_blank">http://lists.puredata.info/listinfo/gem-dev</a><br>
</blockquote></div><br>