Great idea Chris!
Why did I not think of it...
.b.
chris clepper wrote:
Ben
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.
So you can do [pix_buffer biggie 1] and only use 500 frames with no
penalty.
Chris
On Fri, Mar 12, 2010 at 5:12 PM, B. Bogart b...@ekran.org
mailto:b...@ekran.org wrote:
Hey all,
I'm use pix_buffers to store non-sequential images based on index.
I'd like to be able to grow a pix_buffer by 1 element at a time.
[add would add a single slot to the end of the buffer. Its index
would be calculated from the length of the buffer.
The object could initiated as a growing pix_buffer by using a 0 as
the size argument.
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...
Anyhow I'm just thinking aloud here.
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.
.b.
___
GEM-dev mailing list
GEM-dev@iem.at mailto:GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev
