Hi all,
I have started messing with the Gem/Gridflow interoperability. Thanks to Mathieu Bouchard I've learned about the #pix_import and #pix_export through which Gridflow can obtain contents of the Gem window and process them further. Where I am at a loss is when Gridflow processes image and outputs data in "grid" format, how to feed this back to Gem (regular pix format, or whatever that is, is easily returned back via #pix_import, but the "grid" format is giving me trouble)?
The reason for this need is that I would like to maintain Gem window as the only visible window which contains both the output from Gem and Gridflow (i.e. a 3D cube with its faces textured with the output from the Gridflow). Attached patch sort of does that, but without any serious processing from the Gridflow's side (other than capturing the Gem window). The problem is with the part where the really interesting processing takes place in respect to the Gridflow, for instance object #remap_image. This object outputs a "grid" which I have no idea how to convert back to a format that can be imported back to Gem. All linking with Gem objects results in errors of various types suggesting that the two are obviously not compatible.
Any help would be greatly appreciated!
BTW, I am using Gem 0.90 and Gridflow 0.82 (on Linux).
Best wishes,
Ico
#N canvas 125 6 729 655 10; #X obj 111 118 loadbang; #X obj 26 12 gemhead; #X obj 26 333 rotateXYZ; #X obj 35 310 #unpack 3; #X obj 35 253 # +; #X obj 60 253 t a; #X obj 35 272 #cast f; #X obj 35 291 # / (f # 100); #X floatatom 111 31 5 0 0 0 - - -; #X obj 79 12 bang; #X obj 111 12 fps , period 5; #X obj 26 181 pix_texture; #X obj 248 411 #import_pix; #X obj 248 266 t a b; #X msg 287 266 snap; #X obj 248 318 pix_snap; #X obj 263 358 tgl 15 0 empty empty empty 0 -6 0 8 -241291 -1 -1 0 1; #X msg 263 372 yflip $1; #X msg 35 234 30 21 15; #X obj 26 382 cube 4; #X floatatom 151 181 5 0 0 0 - - -; #X msg 270 391 help; #X obj 135 265 tgl 15 0 empty empty empty 0 -6 0 8 -24198 -1 -1 0 1 ; #X obj 152 264 metro 50; #X obj 26 140 pix_video; #X msg 111 140 driver 1; #X obj 100 498 gemwin; #X msg 110 363 create; #X msg 125 397 1; #X msg 134 432 0; #X msg 172 432 destroy; #N canvas 95 194 292 181 Gem.init 0; #X obj 83 30 loadbang; #X msg 161 76 reset; #X obj 134 146 outlet; #X obj 88 51 t b b; #X msg 45 75 dimen 400 400; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 3 0 4 0; #X connect 3 1 1 0; #X connect 4 0 2 0; #X restore 148 481 pd Gem.init; #X obj 608 309 #remap_image; #X obj 465 240 # -; #X obj 465 66 t a a a; #X obj 527 125 # % 2; #X obj 527 144 # * -2; #X obj 527 163 # + 1; #X obj 487 164 # *; #X obj 574 94 # / 2; #X obj 546 29 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -261681 -1 -1 0 1; #X obj 487 145 # -; #X obj 545 54 t f; #X obj 487 126 # %; #X obj 527 106 # /; #X obj 26 75 #export_pix; #X obj 25 206 translateXYZ 0 0 0; #X obj 249 16 gemhead 50; #X obj 336 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 351 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 390 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 405 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 336 76 #unpack; #X obj 389 76 #unpack; #X obj 326 233 #pack; #X obj 323 255 #export_list; #X obj 383 275 #export_list; #X obj 380 233 #pack; #X msg 336 56 128 128; #X msg 389 56 256 256; #X connect 0 0 25 0; #X connect 0 0 58 0; #X connect 0 0 59 0; #X connect 1 0 9 0; #X connect 1 0 45 0; #X connect 2 0 19 0; #X connect 3 0 2 1; #X connect 3 1 2 2; #X connect 3 2 2 3; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 7 0 3 0; #X connect 9 0 10 0; #X connect 10 0 8 0; #X connect 11 0 46 0; #X connect 12 0 11 0; #X connect 12 1 32 0; #X connect 13 0 15 0; #X connect 13 1 14 0; #X connect 14 0 15 0; #X connect 15 0 12 0; #X connect 16 0 17 0; #X connect 17 0 12 0; #X connect 18 0 4 0; #X connect 20 0 46 3; #X connect 21 0 12 0; #X connect 22 0 23 0; #X connect 23 0 18 0; #X connect 24 0 11 0; #X connect 25 0 24 0; #X connect 27 0 26 0; #X connect 28 0 26 0; #X connect 29 0 26 0; #X connect 30 0 26 0; #X connect 31 0 26 0; #X connect 32 1 34 0; #X connect 33 0 32 1; #X connect 34 0 33 0; #X connect 34 1 43 0; #X connect 34 2 44 0; #X connect 35 0 36 0; #X connect 36 0 37 0; #X connect 37 0 38 1; #X connect 38 0 33 1; #X connect 39 0 41 1; #X connect 40 0 42 0; #X connect 41 0 38 0; #X connect 42 0 39 0; #X connect 42 0 43 1; #X connect 42 0 44 1; #X connect 43 0 41 0; #X connect 44 0 35 0; #X connect 45 0 24 0; #X connect 46 0 2 0; #X connect 47 0 13 0; #X connect 48 0 54 0; #X connect 49 0 54 1; #X connect 50 0 57 0; #X connect 51 0 57 1; #X connect 52 0 48 0; #X connect 52 1 49 0; #X connect 53 0 50 0; #X connect 53 1 51 0; #X connect 54 0 55 0; #X connect 55 0 15 1; #X connect 56 0 15 2; #X connect 57 0 56 0; #X connect 58 0 52 0; #X connect 59 0 53 0;
On Tue, 21 Mar 2006, Ivica Ico Bukvic wrote:
Mathieu Bouchard I've learned about the #pix_import and #pix_export
#import_pix and #export_pix
them further. Where I am at a loss is when Gridflow processes image and outputs data in "grid" format, how to feed this back to Gem (regular pix format, or whatever that is, is easily returned back via #pix_import, but the "grid" format is giving me trouble)?
In GridFlow, an image is just a grid whose size is (rows,columns,channels). Channels is 1 for greyscale (Y), 3 for RGB, 3 for YUV, 4 for RGBA, and it's not limited (you can use channels=88 if you have a use for it!)
GridFlow images are a _kind_ of grid. (or maybe saying "subset" is more appropriate...)
The reason for this need is that I would like to maintain Gem window as the only visible window which contains both the output from Gem and Gridflow (i.e. a 3D cube with its faces textured with the output from the Gridflow).
You just have to do #export_pix on every image stream that you want to display.
place in respect to the Gridflow, for instance object #remap_image. This object outputs a "grid" which I have no idea how to convert back to a format that can be imported back to Gem.
[#remap_image] outputs a grid of the same shape as its input, so if you really gave it an image, it'll give you back an image.
All linking with Gem objects results in errors of various types suggesting that the two are obviously not compatible.
In your patch, if I just connect the left outlet of #remap_image to the right inlet of #export_pix, it doesn't produce any errors.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
this is very good news and thanks for sharing Ivica can you share a patch so i may experiment as well? i would like to spigot off pdp/gridflow as an EFX rack if possible
On Mar 21, 2006, at 8:25 AM, Ivica Ico Bukvic wrote:
Hi all,
I have started messing with the Gem/Gridflow interoperability. Thanks to Mathieu Bouchard I've learned about the #pix_import and #pix_export through which Gridflow can obtain contents of the Gem window and process them further. Where I am at a loss is when Gridflow processes image and outputs data in "grid" format, how to feed this back to Gem (regular pix format, or whatever that is, is easily returned back via #pix_import, but the "grid" format is giving me trouble)?
The reason for this need is that I would like to maintain Gem window as the only visible window which contains both the output from Gem and Gridflow (i.e. a 3D cube with its faces textured with the output from the Gridflow). Attached patch sort of does that, but without any serious processing from the Gridflow's side (other than capturing the Gem window). The problem is with the part where the really interesting processing takes place in respect to the Gridflow, for instance object #remap_image. This object outputs a "grid" which I have no idea how to convert back to a format that can be imported back to Gem. All linking with Gem objects results in errors of various types suggesting that the two are obviously not compatible.
Any help would be greatly appreciated!
BTW, I am using Gem 0.90 and Gridflow 0.82 (on Linux).
Best wishes,
Ico
#N canvas 125 6 729 655 10; #X obj 111 118 loadbang; #X obj 26 12 gemhead; #X obj 26 333 rotateXYZ; #X obj 35 310 #unpack 3; #X obj 35 253 # +; #X obj 60 253 t a; #X obj 35 272 #cast f; #X obj 35 291 # / (f # 100); #X floatatom 111 31 5 0 0 0 - - -; #X obj 79 12 bang; #X obj 111 12 fps , period 5; #X obj 26 181 pix_texture; #X obj 248 411 #import_pix; #X obj 248 266 t a b; #X msg 287 266 snap; #X obj 248 318 pix_snap; #X obj 263 358 tgl 15 0 empty empty empty 0 -6 0 8 -241291 -1 -1 0 1; #X msg 263 372 yflip $1; #X msg 35 234 30 21 15; #X obj 26 382 cube 4; #X floatatom 151 181 5 0 0 0 - - -; #X msg 270 391 help; #X obj 135 265 tgl 15 0 empty empty empty 0 -6 0 8 -24198 -1 -1 0 1 ; #X obj 152 264 metro 50; #X obj 26 140 pix_video; #X msg 111 140 driver 1; #X obj 100 498 gemwin; #X msg 110 363 create; #X msg 125 397 1; #X msg 134 432 0; #X msg 172 432 destroy; #N canvas 95 194 292 181 Gem.init 0; #X obj 83 30 loadbang; #X msg 161 76 reset; #X obj 134 146 outlet; #X obj 88 51 t b b; #X msg 45 75 dimen 400 400; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 3 0 4 0; #X connect 3 1 1 0; #X connect 4 0 2 0; #X restore 148 481 pd Gem.init; #X obj 608 309 #remap_image; #X obj 465 240 # -; #X obj 465 66 t a a a; #X obj 527 125 # % 2; #X obj 527 144 # * -2; #X obj 527 163 # + 1; #X obj 487 164 # *; #X obj 574 94 # / 2; #X obj 546 29 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -261681 -1 -1 0 1; #X obj 487 145 # -; #X obj 545 54 t f; #X obj 487 126 # %; #X obj 527 106 # /; #X obj 26 75 #export_pix; #X obj 25 206 translateXYZ 0 0 0; #X obj 249 16 gemhead 50; #X obj 336 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 351 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 390 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 405 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 336 76 #unpack; #X obj 389 76 #unpack; #X obj 326 233 #pack; #X obj 323 255 #export_list; #X obj 383 275 #export_list; #X obj 380 233 #pack; #X msg 336 56 128 128; #X msg 389 56 256 256; #X connect 0 0 25 0; #X connect 0 0 58 0; #X connect 0 0 59 0; #X connect 1 0 9 0; #X connect 1 0 45 0; #X connect 2 0 19 0; #X connect 3 0 2 1; #X connect 3 1 2 2; #X connect 3 2 2 3; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 7 0 3 0; #X connect 9 0 10 0; #X connect 10 0 8 0; #X connect 11 0 46 0; #X connect 12 0 11 0; #X connect 12 1 32 0; #X connect 13 0 15 0; #X connect 13 1 14 0; #X connect 14 0 15 0; #X connect 15 0 12 0; #X connect 16 0 17 0; #X connect 17 0 12 0; #X connect 18 0 4 0; #X connect 20 0 46 3; #X connect 21 0 12 0; #X connect 22 0 23 0; #X connect 23 0 18 0; #X connect 24 0 11 0; #X connect 25 0 24 0; #X connect 27 0 26 0; #X connect 28 0 26 0; #X connect 29 0 26 0; #X connect 30 0 26 0; #X connect 31 0 26 0; #X connect 32 1 34 0; #X connect 33 0 32 1; #X connect 34 0 33 0; #X connect 34 1 43 0; #X connect 34 2 44 0; #X connect 35 0 36 0; #X connect 36 0 37 0; #X connect 37 0 38 1; #X connect 38 0 33 1; #X connect 39 0 41 1; #X connect 40 0 42 0; #X connect 41 0 38 0; #X connect 42 0 39 0; #X connect 42 0 43 1; #X connect 42 0 44 1; #X connect 43 0 41 0; #X connect 44 0 35 0; #X connect 45 0 24 0; #X connect 46 0 2 0; #X connect 47 0 13 0; #X connect 48 0 54 0; #X connect 49 0 54 1; #X connect 50 0 57 0; #X connect 51 0 57 1; #X connect 52 0 48 0; #X connect 52 1 49 0; #X connect 53 0 50 0; #X connect 53 1 51 0; #X connect 54 0 55 0; #X connect 55 0 15 1; #X connect 56 0 15 2; #X connect 57 0 56 0; #X connect 58 0 52 0; #X connect 59 0 53 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Patrick,
Other than what is included below (which is an ugly hack of Mathieu's tutorials), I unfortunately do not have any solutions to the problem stated below. I was actually hoping that someone could help with the issue of converting Gridflow "grid" format to something that can be inputted back into Gem object.
Naturally, the patch below allows you to have processing of Gem window inside Gridflow window, but considering that I see Gridflow more as a texturing element in my upcoming project, I would prefer to project its output onto 3D objects in Gem...
Ico
-----Original Message----- From: Pat Pagano [mailto:bigswift@ufl.edu] Sent: Tuesday, March 21, 2006 10:45 AM To: Ivica Ico Bukvic Cc: pd-list@iem.at; gem-dev@iem.at Subject: Re: [PD] Importing gridflow's grid format in Gem
this is very good news and thanks for sharing Ivica can you share a patch so i may experiment as well? i would like to spigot off pdp/gridflow as an EFX rack if possible
On Mar 21, 2006, at 8:25 AM, Ivica Ico Bukvic wrote:
Hi all,
I have started messing with the Gem/Gridflow interoperability. Thanks to Mathieu Bouchard I've learned about the #pix_import and #pix_export through which Gridflow can obtain contents of the Gem window and process them further. Where I am at a loss is when Gridflow processes image and outputs data in "grid" format, how to feed this back to Gem (regular pix format, or whatever that is, is easily returned back via #pix_import, but the "grid" format is giving me trouble)?
The reason for this need is that I would like to maintain Gem window as the only visible window which contains both the output from Gem and Gridflow (i.e. a 3D cube with its faces textured with the output from the Gridflow). Attached patch sort of does that, but without any serious processing from the Gridflow's side (other than capturing the Gem window). The problem is with the part where the really interesting processing takes place in respect to the Gridflow, for instance object #remap_image. This object outputs a "grid" which I have no idea how to convert back to a format that can be imported back to Gem. All linking with Gem objects results in errors of various types suggesting that the two are obviously not compatible.
Any help would be greatly appreciated!
BTW, I am using Gem 0.90 and Gridflow 0.82 (on Linux).
Best wishes,
Ico
#N canvas 125 6 729 655 10; #X obj 111 118 loadbang; #X obj 26 12 gemhead; #X obj 26 333 rotateXYZ; #X obj 35 310 #unpack 3; #X obj 35 253 # +; #X obj 60 253 t a; #X obj 35 272 #cast f; #X obj 35 291 # / (f # 100); #X floatatom 111 31 5 0 0 0 - - -; #X obj 79 12 bang; #X obj 111 12 fps , period 5; #X obj 26 181 pix_texture; #X obj 248 411 #import_pix; #X obj 248 266 t a b; #X msg 287 266 snap; #X obj 248 318 pix_snap; #X obj 263 358 tgl 15 0 empty empty empty 0 -6 0 8 -241291 -1 -1 0 1; #X msg 263 372 yflip $1; #X msg 35 234 30 21 15; #X obj 26 382 cube 4; #X floatatom 151 181 5 0 0 0 - - -; #X msg 270 391 help; #X obj 135 265 tgl 15 0 empty empty empty 0 -6 0 8 -24198 -1 -1 0 1 ; #X obj 152 264 metro 50; #X obj 26 140 pix_video; #X msg 111 140 driver 1; #X obj 100 498 gemwin; #X msg 110 363 create; #X msg 125 397 1; #X msg 134 432 0; #X msg 172 432 destroy; #N canvas 95 194 292 181 Gem.init 0; #X obj 83 30 loadbang; #X msg 161 76 reset; #X obj 134 146 outlet; #X obj 88 51 t b b; #X msg 45 75 dimen 400 400; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 3 0 4 0; #X connect 3 1 1 0; #X connect 4 0 2 0; #X restore 148 481 pd Gem.init; #X obj 608 309 #remap_image; #X obj 465 240 # -; #X obj 465 66 t a a a; #X obj 527 125 # % 2; #X obj 527 144 # * -2; #X obj 527 163 # + 1; #X obj 487 164 # *; #X obj 574 94 # / 2; #X obj 546 29 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -261681 -1 -1 0 1; #X obj 487 145 # -; #X obj 545 54 t f; #X obj 487 126 # %; #X obj 527 106 # /; #X obj 26 75 #export_pix; #X obj 25 206 translateXYZ 0 0 0; #X obj 249 16 gemhead 50; #X obj 336 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 351 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 390 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 405 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 336 76 #unpack; #X obj 389 76 #unpack; #X obj 326 233 #pack; #X obj 323 255 #export_list; #X obj 383 275 #export_list; #X obj 380 233 #pack; #X msg 336 56 128 128; #X msg 389 56 256 256; #X connect 0 0 25 0; #X connect 0 0 58 0; #X connect 0 0 59 0; #X connect 1 0 9 0; #X connect 1 0 45 0; #X connect 2 0 19 0; #X connect 3 0 2 1; #X connect 3 1 2 2; #X connect 3 2 2 3; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 7 0 3 0; #X connect 9 0 10 0; #X connect 10 0 8 0; #X connect 11 0 46 0; #X connect 12 0 11 0; #X connect 12 1 32 0; #X connect 13 0 15 0; #X connect 13 1 14 0; #X connect 14 0 15 0; #X connect 15 0 12 0; #X connect 16 0 17 0; #X connect 17 0 12 0; #X connect 18 0 4 0; #X connect 20 0 46 3; #X connect 21 0 12 0; #X connect 22 0 23 0; #X connect 23 0 18 0; #X connect 24 0 11 0; #X connect 25 0 24 0; #X connect 27 0 26 0; #X connect 28 0 26 0; #X connect 29 0 26 0; #X connect 30 0 26 0; #X connect 31 0 26 0; #X connect 32 1 34 0; #X connect 33 0 32 1; #X connect 34 0 33 0; #X connect 34 1 43 0; #X connect 34 2 44 0; #X connect 35 0 36 0; #X connect 36 0 37 0; #X connect 37 0 38 1; #X connect 38 0 33 1; #X connect 39 0 41 1; #X connect 40 0 42 0; #X connect 41 0 38 0; #X connect 42 0 39 0; #X connect 42 0 43 1; #X connect 42 0 44 1; #X connect 43 0 41 0; #X connect 44 0 35 0; #X connect 45 0 24 0; #X connect 46 0 2 0; #X connect 47 0 13 0; #X connect 48 0 54 0; #X connect 49 0 54 1; #X connect 50 0 57 0; #X connect 51 0 57 1; #X connect 52 0 48 0; #X connect 52 1 49 0; #X connect 53 0 50 0; #X connect 53 1 51 0; #X connect 54 0 55 0; #X connect 55 0 15 1; #X connect 56 0 15 2; #X connect 57 0 56 0; #X connect 58 0 52 0; #X connect 59 0 53 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
To use #pix_import, the grid must be in RGBA format I think.
Tom
On 3/21/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
Hi Patrick,
Other than what is included below (which is an ugly hack of Mathieu's tutorials), I unfortunately do not have any solutions to the problem stated below. I was actually hoping that someone could help with the issue of converting Gridflow "grid" format to something that can be inputted back into Gem object.
Naturally, the patch below allows you to have processing of Gem window inside Gridflow window, but considering that I see Gridflow more as a texturing element in my upcoming project, I would prefer to project its output onto 3D objects in Gem...
Ico
-----Original Message----- From: Pat Pagano [mailto:bigswift@ufl.edu] Sent: Tuesday, March 21, 2006 10:45 AM To: Ivica Ico Bukvic Cc: pd-list@iem.at; gem-dev@iem.at Subject: Re: [PD] Importing gridflow's grid format in Gem
this is very good news and thanks for sharing Ivica can you share a patch so i may experiment as well? i would like to spigot off pdp/gridflow as an EFX rack if possible
On Mar 21, 2006, at 8:25 AM, Ivica Ico Bukvic wrote:
Hi all,
I have started messing with the Gem/Gridflow interoperability. Thanks to Mathieu Bouchard I've learned about the #pix_import and #pix_export through which Gridflow can obtain contents of the Gem window and process them further. Where I am at a loss is when Gridflow processes image and outputs data in "grid" format, how to feed this back to Gem (regular pix format, or whatever that is, is easily returned back via #pix_import, but the "grid" format is giving me trouble)?
The reason for this need is that I would like to maintain Gem window as the only visible window which contains both the output from Gem and Gridflow (i.e. a 3D cube with its faces textured with the output from the Gridflow). Attached patch sort of does that, but without any serious processing from the Gridflow's side (other than capturing the Gem window). The problem is with the part where the really interesting processing takes place in respect to the Gridflow, for instance object #remap_image. This object outputs a "grid" which I have no idea how to convert back to a format that can be imported back to Gem. All linking with Gem objects results in errors of various types suggesting that the two are obviously not compatible.
Any help would be greatly appreciated!
BTW, I am using Gem 0.90 and Gridflow 0.82 (on Linux).
Best wishes,
Ico
#N canvas 125 6 729 655 10; #X obj 111 118 loadbang; #X obj 26 12 gemhead; #X obj 26 333 rotateXYZ; #X obj 35 310 #unpack 3; #X obj 35 253 # +; #X obj 60 253 t a; #X obj 35 272 #cast f; #X obj 35 291 # / (f # 100); #X floatatom 111 31 5 0 0 0 - - -; #X obj 79 12 bang; #X obj 111 12 fps , period 5; #X obj 26 181 pix_texture; #X obj 248 411 #import_pix; #X obj 248 266 t a b; #X msg 287 266 snap; #X obj 248 318 pix_snap; #X obj 263 358 tgl 15 0 empty empty empty 0 -6 0 8 -241291 -1 -1 0 1; #X msg 263 372 yflip $1; #X msg 35 234 30 21 15; #X obj 26 382 cube 4; #X floatatom 151 181 5 0 0 0 - - -; #X msg 270 391 help; #X obj 135 265 tgl 15 0 empty empty empty 0 -6 0 8 -24198 -1 -1 0 1 ; #X obj 152 264 metro 50; #X obj 26 140 pix_video; #X msg 111 140 driver 1; #X obj 100 498 gemwin; #X msg 110 363 create; #X msg 125 397 1; #X msg 134 432 0; #X msg 172 432 destroy; #N canvas 95 194 292 181 Gem.init 0; #X obj 83 30 loadbang; #X msg 161 76 reset; #X obj 134 146 outlet; #X obj 88 51 t b b; #X msg 45 75 dimen 400 400; #X connect 0 0 3 0; #X connect 1 0 2 0; #X connect 3 0 4 0; #X connect 3 1 1 0; #X connect 4 0 2 0; #X restore 148 481 pd Gem.init; #X obj 608 309 #remap_image; #X obj 465 240 # -; #X obj 465 66 t a a a; #X obj 527 125 # % 2; #X obj 527 144 # * -2; #X obj 527 163 # + 1; #X obj 487 164 # *; #X obj 574 94 # / 2; #X obj 546 29 hsl 128 15 0 127 0 0 empty empty empty -2 -6 0 8 -261681 -1 -1 0 1; #X obj 487 145 # -; #X obj 545 54 t f; #X obj 487 126 # %; #X obj 527 106 # /; #X obj 26 75 #export_pix; #X obj 25 206 translateXYZ 0 0 0; #X obj 249 16 gemhead 50; #X obj 336 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 351 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 390 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 405 99 vsl 15 128 0 512 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 336 76 #unpack; #X obj 389 76 #unpack; #X obj 326 233 #pack; #X obj 323 255 #export_list; #X obj 383 275 #export_list; #X obj 380 233 #pack; #X msg 336 56 128 128; #X msg 389 56 256 256; #X connect 0 0 25 0; #X connect 0 0 58 0; #X connect 0 0 59 0; #X connect 1 0 9 0; #X connect 1 0 45 0; #X connect 2 0 19 0; #X connect 3 0 2 1; #X connect 3 1 2 2; #X connect 3 2 2 3; #X connect 4 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 7 0 3 0; #X connect 9 0 10 0; #X connect 10 0 8 0; #X connect 11 0 46 0; #X connect 12 0 11 0; #X connect 12 1 32 0; #X connect 13 0 15 0; #X connect 13 1 14 0; #X connect 14 0 15 0; #X connect 15 0 12 0; #X connect 16 0 17 0; #X connect 17 0 12 0; #X connect 18 0 4 0; #X connect 20 0 46 3; #X connect 21 0 12 0; #X connect 22 0 23 0; #X connect 23 0 18 0; #X connect 24 0 11 0; #X connect 25 0 24 0; #X connect 27 0 26 0; #X connect 28 0 26 0; #X connect 29 0 26 0; #X connect 30 0 26 0; #X connect 31 0 26 0; #X connect 32 1 34 0; #X connect 33 0 32 1; #X connect 34 0 33 0; #X connect 34 1 43 0; #X connect 34 2 44 0; #X connect 35 0 36 0; #X connect 36 0 37 0; #X connect 37 0 38 1; #X connect 38 0 33 1; #X connect 39 0 41 1; #X connect 40 0 42 0; #X connect 41 0 38 0; #X connect 42 0 39 0; #X connect 42 0 43 1; #X connect 42 0 44 1; #X connect 43 0 41 0; #X connect 44 0 35 0; #X connect 45 0 24 0; #X connect 46 0 2 0; #X connect 47 0 13 0; #X connect 48 0 54 0; #X connect 49 0 54 1; #X connect 50 0 57 0; #X connect 51 0 57 1; #X connect 52 0 48 0; #X connect 52 1 49 0; #X connect 53 0 50 0; #X connect 53 1 51 0; #X connect 54 0 55 0; #X connect 55 0 15 1; #X connect 56 0 15 2; #X connect 57 0 56 0; #X connect 58 0 52 0; #X connect 59 0 53 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
To use #pix_import, the grid must be in RGBA format I think.
Tom
Thank you for your help! Do you mind providing a simple example of how to convert that based upon my submitted patch (namely in the right bottom corner there is a #remap_image object whose output I would like to link to the pix_texture object which is part of the Gem window)or simply by showing a sequence of objects, i.e.:
#remap_image -> ??? -> pix_texture (or #pix_import -> pix_texture)
Many thanks!
Ico
hi August and list,
using Pd39.2 with readanysf and flext from cvs, i often get an error message when saving a subpatch which contains the readanysf~ object (this is sometime annoying) but does not affect the great features of this object.
the error is of the type:
*** glibc detected *** free(): invalid pointer: 0x84113ac *** Pd: signal 6
btw, there is still this compilation pb due to the fact that flext now creates a lib called flext-pd: last compilation step should be:
g++ -DFLEXT_SYS=2 -DFLEXT_THREADS -DFLEXT_SHARED -DFLEXT_NOGLOBALNEW -DREAD_VORBIS -DREAD_MAD -DREAD_FLAC -L/usr/local/lib -ldl -shared -o readanysf~.pd_linux Fifo.o Input.o InputFile.o InputStream.o ReadRaw.o Readsf.o main.o ReadMad.o ReadVorbis.o ReadFlac.o -lflext-pd -lpthread -lsamplerate -lflext-pd -logg -lvorbis -lvorbisfile -lmad -lFLAC
best regards, vincent
hi August and list,
using Pd39.2 with readanysf and flext from cvs, i often get an error message when saving a subpatch which contains the readanysf~ object (this is sometime annoying) but does not affect the great features of this object.
I made some bug fixes in december that I think fixed this.
Try here: http://aug.ment.org/readanysf/download.php
I'd upload it into CVS but I do not have permissions. Someone did it for me last time, and that was a while ago.
-august.
the error is of the type:
*** glibc detected *** free(): invalid pointer: 0x84113ac *** Pd: signal 6
btw, there is still this compilation pb due to the fact that flext now creates a lib called flext-pd: last compilation step should be:
g++ -DFLEXT_SYS=2 -DFLEXT_THREADS -DFLEXT_SHARED -DFLEXT_NOGLOBALNEW
-DREAD_VORBIS -DREAD_MAD -DREAD_FLAC -L/usr/local/lib -ldl -shared -o readanysf~.pd_linux Fifo.o Input.o InputFile.o InputStream.o ReadRaw.o Readsf.o main.o ReadMad.o ReadVorbis.o ReadFlac.o -lflext-pd -lpthread
-lsamplerate -lflext-pd -logg -lvorbis -lvorbisfile -lmad -lFLACbest regards, vincent
Hallo!
I'd upload it into CVS but I do not have permissions. Someone did it for me last time, and that was a while ago.
maybe your file externals/august/readanysf~/CVS/Root does not look like this:
:ext:your_user_name@cvs.sourceforge.net:/cvsroot/pure-data
otherwise I can commit it for you if you want ...
LG Georg
On Wed, 22 Mar 2006, Georg Holzmann wrote:
I'd upload it into CVS but I do not have permissions. Someone did it for me last time, and that was a while ago.
maybe your file externals/august/readanysf~/CVS/Root does not look like this: :ext:your_user_name@cvs.sourceforge.net:/cvsroot/pure-data otherwise I can commit it for you if you want ...
There's a script in GridFlow's repository that can switch the user of a checkout without having to make a new checkout and move files around etc.
That's super-useful if you need to make commits from a checkout that is usually reserved for mere mortals.
I use it like: bin/cvs-switch-user :ext:matju or bin/cvs-switch-user :pserver:anonymous
Note that when it works it just prints a warning saying it can't overwrite "CVS/Root" with itself ;-) ignore it. Here's the file, which could be modified for Pd:
------------------8<--------cut-here--------8<------------------
GFSOURCE=$(dirname $(dirname $(which "$0"))) echo $1@cvs.gridflow.ca:/home/cvs/gridflow > CVS/Root for file in $(find $GFSOURCE -name Root) do cp CVS/Root $file done
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
I'd upload it into CVS but I do not have permissions. Someone did it for me last time, and that was a while ago.
maybe your file externals/august/readanysf~/CVS/Root does not look like this:
:ext:your_user_name@cvs.sourceforge.net:/cvsroot/pure-data
otherwise I can commit it for you if you want ...
yes, please do.
thanks -august.
On Tue, 21 Mar 2006, Ivica Ico Bukvic wrote:
#remap_image -> ??? -> pix_texture (or #pix_import -> pix_texture)
[gemhead] ... | [#import_pix] | [#remap_image]X[blahblah] [gemhead] | | | [#export_pix] | [pix_texture] ...
Both gemheads may be the same, or not. By the way you order the gem operations you can get either a 1-frame delay or no delay. (just like in the rest of GEM and of GridFlow)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Thank you very much for all your help and for the Gridflow!
Best wishes,
Ico
-----Original Message----- From: Mathieu Bouchard [mailto:matju@artengine.ca] Sent: Tuesday, March 21, 2006 6:16 PM To: Ivica Ico Bukvic Cc: tom@danslchamp.org; pd-list@iem.at; gem-dev@iem.at; 'Pat Pagano' Subject: Re: [GEM-dev] RE: [PD] Importing gridflow's grid format in Gem
On Tue, 21 Mar 2006, Ivica Ico Bukvic wrote:
#remap_image -> ??? -> pix_texture (or #pix_import -> pix_texture)
[gemhead] ... | [#import_pix] | [#remap_image]X[blahblah] [gemhead] | | | [#export_pix] | [pix_texture] ...
Both gemheads may be the same, or not. By the way you order the gem operations you can get either a 1-frame delay or no delay. (just like in the rest of GEM and of GridFlow)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, 21 Mar 2006, Thomas Ouellet Fredericks wrote:
To use #pix_import, the grid must be in RGBA format I think.
[#remap_image] preserves the number of channels and their meaning. [#export_pix] outputs in RGBA so [#remap_image] has to output in RGBA as well.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
august -
Georg Holzmann -
Ivica Ico Bukvic -
Mathieu Bouchard -
Pat Pagano -
Thomas Ouellet Fredericks -
vincent rioux