[GEM-dev] pix_buffer* & pix_write

[B. Bogart]

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 at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060223/701eb52c/attachment.pgp>