Re: [GEM-dev] pix_buffer_share?

I understand that it would be nice to have a central buffer shared between several instance of Pd/GEM.

I have, here, a new patch using 3 instances, 1 for the buffer and where you manage the picture you want to send to the id of [pix_share_read] (of course, it's working only if you have not 50 instances ;) but a small number), 2 others instances are used to receive the picture and choose the picture you want to load.

You have only one buffer (no problem for memory) and you can manage which picture you want from the 2 instances (with [pix_share_read]) if you use [netsend]/[netreceive].

I use 'buffer 1' to manage the 'main patch' with the buffer.

Maybe, this patch could be useful for someone ? I don't know :) ++

Jack

Le 6 mars 09 à 23:01, B. Bogart a écrit :

Thanks Chris + Jack,

This is already how I'm using pix_share.

I'm not using it to transport video but a data-base of random access frames.

Ideally I'd be able to share the whole pix_buffer, rather than:

• iterating over each frame a dumping it into a pix_share to be read

into another buffer in the other PD process. (not very memory efficient)

• Use a separate pix_share for each slot in the pix_buffer. (This

is not very scalable, my patch currently has 2500 slots.)

I think a [pix_buffer_share] would be a useful object for cases when one wants to share more than a single frame.

There I go, dreaming again.

.b.

chris clepper wrote:

...

pix_share does do exactly what you ask. The same buffer is used for both read and write and I moved 1920x1080@30fps between processes with no problem.

On Fri, Mar 6, 2009 at 12:59 PM, B. Bogart <ben@ekran.org mailto:ben@ekran.org> wrote:

Hey all,

Is there a way to share a whole pix_buffer between PD processes?

I'm running my SOM stuff in a second PD instance (to make use  

of the second core in my installation machine). But as I'm developing both PD instances are getting more coupled and I'd like to share a whole pix_buffer.

The alternative is using two [pix_share]s, one for input the  

other for output, controlled by netsend. The problem with this is that I need to send a lot of data quickly, 10ms between new images, and I think that could cause lots of problems.

I don't think I'll be able to get the CPU usage of the second  

patch down low enough to not interfere with rendering in the main PD patch.

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