Hi Chris,

This is true that I could "load" a black pixel texture to make black, and I'll probably do that, but really I'm talking about being able to have a kind of default colour for a texture that has not yet been set, white is great for debugging and seeing what is going on, but it would be nice to be able to set it for slots in the depot that have not yet been saved. I could also make the uncaptured slots transparent, but I think these are more workaround.

Yes, Johannes reminded me of "open" which scratches that one of the list. Please add it to the CVS help-patch! :) (or wait to my second email)

As for loading and saving images I do not know of a way of doing this without interfering with the gemwindow. That is I want to save something that is in the pix_buffer memory, but is not visible on the screen... I'd love to know how to do this at the patch level, please let me know.

As for pix_write I was not thinking of writing the gemlist itself, but rather doing a "normal" pix_write capture of the whole screen, except only including one gemlist (the one its conatined in). I could also do this with setting my gemlist render priorities carefully, but I have something like 10x60 gemlists so Its not likely to happen that way for this project. Actually now that I think about it, its more or less a workaround for the ability to save something in the buffer, but having to mess with putting the image I want to save in the gemwindow first, which is not possible in most cases.

More or less pix_write is a misleading name, since it should only save the texture and not the whole buffer... I can't think of another pix_ object that does not deal with textures...

I have not tried pix_record, sounds really amazing.

Ok, onto Johannes's email.

.b.

chris clepper wrote:

While I think some of these are good ideas relating to pix_buffer, none of them strike me as something which can only be done on the C code level or would pose some great advantage by doing it there - the possbile exception might be the clearing code. Loading and saving images can be done on the patching level using existing objects.

I have no idea what you would do with a gemlist written to a file. It doesn't strike me as something that would be useful for later apart from possibly debugging. What is your reasoning behind this request?

cgc

On 2/22/06, *B. Bogart* <ben@ekran.org mailto:ben@ekran.org> wrote:

Hey all,

So I've been working a lot with the pix_buffer (depot) stuff and had a
few ideas that would make using it even more useful:

* The ability to colour the buffer black, effectively clearing it
without deallocating memory.

* The ability to load and save the images in a buffer, basically being
able to take a snapshot of the system so that the same images that were
in the buffers can be reloaded, restoring the original state.

* It would be also nice to be able to save a particular frame rather
than the whole buffer.

"load [filename]"
to pix_buffer_read could load the [filename] into the slot already set
by the pix_buffer_read index. "load [wildcard] 10" would load 10 images
matching the wildcard pattern into 10 slots (reallocate if needed?)

"save [filename]" to pix_buffer_write would save the image in the
current slot to that filename. "save [filename] 10" could save images
from the first 10 slots to filename with an id appended: "file0000",
"file0001" etc..

"clear 10" or "clear" to pix_write would clear the first 10 slots, or
the current slot respectively. "black" may work instead of the word
"clear".

Oh and It would be amazing if you could put pix_write in a gemchain and
have it only capture that gemlist in the buffer... or maybe the current
pix_write should be called something like window_write since it does
not
actually save what is happening in the pix_ of a chain...

Thanks!

.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

Hi Johannes,

Yup arbitrary setting colour sounds perfect. (just making slow moves. ;) could be neat to be able to do that to pix_texture as well for those projects that start with empty textures, and of course I realize you could set the colour of the gemlist to match what you want, and then as soon as you put the texture on it, reset the colour back to white. But that is not a default state as I was imaginging the feature being used.

Your right that it would be easy to choose a frame, but what if you want to save a specific frame you already know you want, but know you don't want to save all of them? But I would certainly be happy just to save the whole buffer, since for this project it would make a really nice archive. (I'm only holding about 6x100 frames now, so there are only 6 slots in each depot and the older images get overwritten. It would be nice to save each frame before it gets overwritten, rather than the whole collection. I can work around it either way.

I was actually thinking johannes that having "open" "save" as method to the [pix_buffer] itself is the best place, as well as setting the default colour of a slot.

It seems awkward and a little strange that the only way to set the state of a buffer slot would be through *_write and *_read. maybe the image loading/saving would happen through pixfiler. :)

I think my comments to Chris will clarify the pix_write comment, but that idea was not very thought out, and just caries a bit of convienence value for now, but I'd be happier with being able to save the pix_buffers and I'll impliment the idea of setting the colour with a "opening" a texture.

Does the "open" message go to [pix_buffer] ?

.b.

IOhannes m zmoelnig wrote:

B. Bogart wrote:

...

Hey all,

So I've been working a lot with the pix_buffer (depot) stuff and had a few ideas that would make using it even more useful:

• The ability to colour the buffer black, effectively clearing it

without deallocating memory.

when we are there, why not set it to an arbitrary color? (i am not so a big fan of named colors and prefer a numerical representation)

...

• The ability to load and save the images in a buffer, basically being

able to take a snapshot of the system so that the same images that were in the buffers can be reloaded, restoring the original state.

...

• It would be also nice to be able to save a particular frame rather

than the whole buffer.

well this is something i wouldn't really care about. if the whole buffer is saved, people have the choice to pick their favourite frame with external software.

...

"load [filename]" to pix_buffer_read could load the [filename] into the slot already set by the pix_buffer_read index. "load [wildcard] 10" would load 10 images matching the wildcard pattern into 10 slots (reallocate if needed?)

have you ever tried to send [open <filename> <slot>( to [pix_buffer] ??

...

"save [filename]" to pix_buffer_write would save the image in the current slot to that filename. "save [filename] 10" could save images from the first 10 slots to filename with an id appended: "file0000", "file0001" etc..

storing the buffer to disk is on my todo-list.

there has been some discussion about how to interface the pix-buffer via objects. i still think that [pix_buffer_write] is the wrong place to store the images to disk and i prefer [pix_buffer] (see the archives on more info).

basically [pix_buffer] is something like a [table], and [pix_buffer_read] is like [tabread].

...

Oh and It would be amazing if you could put pix_write in a gemchain and have it only capture that gemlist in the buffer... or maybe the current pix_write should be called something like window_write since it does not actually save what is happening in the pix_ of a chain...

[pix_write] has been an error in the first place: reading the gl-buffer and writing them to disk should have always been separated into 2 objects. i recommend using [pix_snap]) and [pix_record] (though [pix_record] is still a bit unstable on linux with certain codecs - any help welcome :-))

mfg.asd.r IOhannes

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev