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.
Le vendredi 12 mars 2010 à 14:12 -0800, B. Bogart a écrit :
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.
In this case, you can use [pix_texture] to store your 'image' instead of [pix_buffer]. ++
Jack
.b.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hi Jack,
How would the annoyance of dynamic patching many pix_buffers be helped by needing many gemlists?
For the record, this is for storage, not for rendering. The gfx card will certainly not have enough memory to store what I'll need to, 1000s of high-res images...
.b.
Jack wrote:
Le vendredi 12 mars 2010 à 14:12 -0800, B. Bogart a écrit :
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.
In this case, you can use [pix_texture] to store your 'image' instead of [pix_buffer]. ++
Jack
.b.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
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 ben@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 http://lists.puredata.info/listinfo/gem-dev
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 10000] and only use 500 frames with no penalty.
Chris
On Fri, Mar 12, 2010 at 5:12 PM, B. Bogart <ben@ekran.org mailto:ben@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
-
B. Bogart -
chris clepper -
Jack