Le 11 avr. 08 à 12:09, IOhannes m zmoelnig a écrit :

Raphaël ILIAS wrote:

...

hi list ! i'm working on live-captured video treatment with gem. the main
patch is okay, but in order to get a convenient improvisation tool, i would
like to have a "control monitor" with another content that what's
dsiplayed on the main gemwin (which is shown to the audience)... captured frames are stored in a pix_buffer (360x288px on 1 channel - grey) and i thought to send them to another computer with its own
gemwin in which they might be displayed (for the performer)... i tried with on one side, [pix_dump] and [netsend] and, on the other computer, [netreceive] and [pix_set]... it was very slow, and crashed... so, i reduced the picture to
45x36 px and split the pix-list into packets of 100 floats. i finally got a picture, but lines aren't synchronized (i get "diagonals"), and i
don't understand why... does someone see an easier solution to pass pixes through a local network ? i don't care a lot about latency (hem...less than 10
seconds of course) and resolution...

on osx and linux you can use [pix_share_read] and [pix_share_write] to share images between two instances of Pd/Gem on one(!) computer via shared-memory. this should be very fast.

About [pix_share_read] and [pix_share_write]. Is there a method using
this two objects to share a picture that come from a
[gemframebuffer] ? I think is not possible. Am I wrong ? ++

Jack

afair, there are some freeframe-plugins that allow you to send images from one host to another (via network), but i don't know on which platform they are available (i guess: w32) and whether they are
free; i never tried them, but they should be usable with [pix_freeframe].

depending on what you are doing, it might be easiest to just run 2 (synched) instances of Gem that independently produce the 2 visuals
(and are controlled by a single patch)

or use a multi-monitor setup and do clever things to get 2 virtual monitors in a single gemwindow.

or pay the developers a lot of money to finally get the multi-window support into Gem which i have been promising for more than 3 years :-)

fgamdsr IOhannes

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

Claude Heiland-Allen wrote:

Jack wrote:

...

About [pix_share_read] and [pix_share_write]. Is there a method using
this two objects to share a picture that come from a
[gemframebuffer] ? I think is not possible. Am I wrong ?

As far as I know (correct me if I'm wrong!), [gemframebuffer] stores images in GPU memory, you need to get it back to CPU memory as a pix, using eg [pix_snap], but that only snaps what is currently displayed (not from a framebuffer) (again correct me if I'm wrong).

you mean, like that?

And in my experience with oldish AGP graphics cards, GPU->CPU image copying is rather slow. PCIe may be better, I don't know.

to my knowledge, this is correct.

fmgadsr IOhannes

#N canvas 507 232 742 523 10; #X msg 65 67 create , 1; #X obj 82 176 gemhead 20; #X obj 82 200 gemframebuffer; #X msg 179 171 dimen 256 256; #X obj 114 310 rotateXYZ; #X obj 114 355 teapot; #X obj 82 246 t a a b; #X obj 137 272 i; #X obj 170 271 + 1; #X obj 200 270 % 360; #X obj 81 383 t a b; #X msg 129 383 snap; #X obj 80 442 t a b; #X msg 135 443 1; #X obj 80 467 pix_buffer_write $0-framebuffer; #X obj 410 202 gemhead 30; #X obj 410 246 t a b; #X msg 465 247 1; #X obj 410 271 pix_buffer_read $0-framebuffer; #X obj 410 351 pix_texture; #X obj 410 416 square 3; #X obj 65 112 gemwin; #X obj 340 90 pix_buffer $0-framebuffer 2; #X obj 82 223 translateXYZ 0 0 -4; #X obj 81 418 pix_snap 0 0 256 256; #X obj 562 182 gemhead 5; #X obj 569 209 world_light; #X msg 129 100 lighting 1; #X obj 114 332 color 1 0 1; #X floatatom 173 292 5 0 0 0 - - -; #X obj 410 310 pix_aging; #X obj 410 393 rotateXYZ; #X floatatom 445 373 5 0 0 0 - - -; #X connect 0 0 21 0; #X connect 1 0 2 0; #X connect 2 0 23 0; #X connect 3 0 2 0; #X connect 4 0 28 0; #X connect 6 0 10 0; #X connect 6 1 4 0; #X connect 6 2 7 0; #X connect 7 0 8 0; #X connect 7 0 4 1; #X connect 7 0 4 2; #X connect 8 0 9 0; #X connect 9 0 7 1; #X connect 10 0 24 0; #X connect 10 1 11 0; #X connect 11 0 24 0; #X connect 12 0 14 0; #X connect 12 1 13 0; #X connect 13 0 14 1; #X connect 15 0 16 0; #X connect 16 0 18 0; #X connect 16 1 17 0; #X connect 17 0 18 1; #X connect 18 0 30 0; #X connect 19 0 31 0; #X connect 23 0 6 0; #X connect 24 0 12 0; #X connect 25 0 26 0; #X connect 27 0 21 0; #X connect 28 0 5 0; #X connect 29 0 4 3; #X connect 30 0 19 0; #X connect 31 0 20 0; #X connect 32 0 31 2;