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 10000] and only use 500 frames with no penalty. Chris On Fri, Mar 12, 2010 at 5:12 PM, B. Bogart <[email protected]> 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 > [email protected] > http://lists.puredata.info/listinfo/gem-dev >
_______________________________________________ GEM-dev mailing list [email protected] http://lists.puredata.info/listinfo/gem-dev
