if you send "0" to the first inlet (the one with the gemlist) of a pix_fx, it will be turned off. sending it "1", turns it - suprisingly - on.

but this way you cannot add fx dynamically.

So, every [pix_*] object behave like this ?

Does it save on CPU+RAM performance when it is set to 0 ? Otherwise, would [spygot] be more suitable ? For instance, does change the gemlist path with spygot create new instances of the gemlist "object" every time one changes the flow ?

aalex

Ive created a patch and framework that allow one to dynamically route
pix data to various pix objects. I havent used it extensively, but it
essentially goes like:

[gemhead] | [pix_film] | [send13 movie1]

... some effect module:

[someOtherPixSource( | [movie 1( |/ [recieve13] | [separator] | [pix_effect_here] | [send13 effectOut1]

etc etc.

the send receives can be dynamically set via a pulldown menu, or
whatnot. also, be sure to quickly toggle rendering on and off to make
sure you dont get hiccups (at least with older gem versions)

You can get trickier by removing the separators if you make sure to
always reset the rendering [stop,start( to gemwin, but it requires
more logic in the patch. The above method isnt all that efficient,
but does allow for dynamic routing of effects. You could event script
it to spawn new effect modules for arbitrary length effect chains,
but there arent really enough pix_ effects to make that worthwhile I
dont think. Also, beware of colorspace issues that some of the
pix_effects have. I try to stick to YUV, since it is fastest.

peace. (send13/recieve13 use the max/MSP syntax to dynamically set
their send target and receive target..)

v a d e //

http://homepage.mac.com/doktorp/ doktorp@mac.com

On Jul 13, 2005, at 1:10 PM, IOhannes m zmoelnig wrote:

Alexandre Quessy wrote:

...

...

So, every [pix_*] object behave like this ?

at least each and every pix_fx (there might be one or 2 pix_objects
that do not behave like that, probably [pix_draw] and [pix_texture], i
really dunno. all other pix_objects behave like that (the joys of
inheritance)

...

Does it save on CPU+RAM performance when it is set to 0 ?

well it just ignores the actual processing for this object. this means it doesn't do anything but pass the gemlist on (so yes, this saves
CPU+RAM)

...

Otherwise, would [spygot] be more suitable ? For instance, does
change the gemlist path with spygot create new instances of the gemlist "object" every time one changes the flow ?

i am not entirely sure what you mean, but you can definitely change
the render-chain with flow-control objects like [spigot], [demux], [repeat],... (the last 2 being zexy)

mfg.asd.r IOhannes

---

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

er, shite, my psuedo code meant to have [pix_separator] rather than
[separator] in there. Sorry. its 2:30 am here on the east coast and I
really ought to be alseep :)

iohannes is 100% correct. (separator is used later in the patch to
shoot different translates/rotates/ to different final output geometry)

v a d e //

http://homepage.mac.com/doktorp/ doktorp@mac.com

On Jul 14, 2005, at 2:27 AM, IOhannes m zmoelnig wrote:

vade wrote:

...

Ive created a patch and framework that allow one to dynamically route pix data to various pix objects. I havent used it extensively, but it essentially goes like:

[gemhead] | [pix_film] | [send13 movie1]

... some effect module:

[someOtherPixSource( | [movie 1( |/ [recieve13] | [separator] |

btw, you only need [separator] if you are doing something with
openGL in the sub-lists: [separator] pushes the openGL stack before executing
the sub-list and pops it after it has finished. if you are only doing pix-manipulations, then the [separator] will
have no benefit.

but of course this depends on your entire patch.

mfg.asd.r IOhannes