[PD] gem renderchain question..
zmoelnig at iem.at
zmoelnig at iem.at
Sun Oct 26 19:19:09 CET 2003
Zitiere doktorp <doktorp at mac.com>:
> ill try the pix_separate as cgc noted. I didnt see that listed anywhere
> in the docs. *shrug*
> oh well.
> as far as turning on and off the effects on a renderchain, at least, in
> jitter, there is overhead for even passing through an effect that is
> off. there is a 'passthrough' command , similar to natos 'thru', but
> even that has overhead. =(
if you turn the fx on/off with 0/1 as ben (i think) has mentioned , you will get
almost no overhead (it will cost more than without the object plugged in, but i
think almost any routing object (like [spigot]) would cost the same...), no void
data-copying is done.
and you will get an overhead when using [trigger anything] too, but you could
just ignore it.
> so thats what I was trying to avoid.
> GEM: Graphics Environment for Multimedia
> GEM: ver: 0.87+cvs
> GEM: compiled: Aug 6 2003
> is this new enough to have that new message system?, and how often does
> the OS X image installer get updated (that is what I used)? and how
> clean will it do an upgrade? (IE replace/overwrite etc old externals.)
> I have noticed that after playing for a while with routing gem chains
> here and there (is gem-chain even the right name.. ?), that the video
> would get a bit messed up.
basically image-processing is done in-place (so we don't have to do costy
image-copying), which means that the image-itself is modified ("destructive
editing"), which is normally no problem when using live-feeds (because you will
get a fresh and brand-new image in the next frame), but is bad when using
subchains with independent pix_fx.
however, [pix_separator] (or [pix_buf], which is the same) just buffers the
image (doing costy copying) which helps you in several cases (separate
gem-subchains, where you want different independent image-fx)
> Ive also managed to crash PD/Gem quite a bit. who do I send crashlogs
any othere volunteers ?
More information about the Pd-list