Hi all, I'm wondering if an object exists that can act as a 'switch'. What I mean is that when it is in one state, the signal flow continues in one direction and when in the other it goes in another direction, basically deactivating the other branch. What I want to do is split a gem list in two, so when the switch is in one state one type of processing is done, and another type of process is done when the switch is in another state. All this to save cpu, since both processes could be placed inline, but would consume too much cpu. I'm thinking specifically of live video processing. Is there an object to do this, or can anyone think of a way to do this?
Thanks all!
acabrera@teleset.com.co wrote:
Hi all, I'm wondering if an object exists that can act as a 'switch'. What I mean is that when it is in one state, the signal flow continues in one direction and when in the other it goes in another direction, basically deactivating the other branch.
yes, pd's [spigot] can "gate" message-flow. using to parallel (one with inverse logic) [spigot]s will do what you want. (refer to pd's manual) another way is zexy's [demux], which demultiplexes one message-stream to one-of-many branches.
What I want to do is split a gem list in two, so when the switch is in one state one type of processing is done, and another type of process is done when the switch is in another state. All this to save cpu, since both processes could be placed inline, but would consume too much cpu.
I'm thinking specifically of live video processing.
and you can turn on/off most (i'd rather say: all) [pix_]-objects by simply sending 1/0 to their leftmost inlet (the one, the GemList goes into)
me, i use [demux] for your kind of problem (because of personal likings)
mfg.a.sdr IOhannes
I'm wondering if an object exists that can act as a 'switch'. What I mean is that when it is in one state, the signal flow continues in one direction and when in the other it goes in another direction, basically deactivating the
theres surely a dozen more ways to do this, but a toggle & a pair of spigots fed with == 0 and == 1//
the switch is in another state. All this to save cpu, since both processes could be placed inline, but would consume too much cpu.
suppose you have two subpatches both heavily taxing the cpu with audio-rate signal processing, but due to your switch, you only want one of them on at once. is there a way to selectively disable dsp on a subpatch basis? i saw something in the help files about a similar trick for blocksize, but perhaps i havent dug deep enough to into the scheduler code or help files to know if something like a simple toggle .x40203 DSP 0 method exists..
theres surely a dozen more ways to do this, but a toggle & a pair of spigots fed with == 0 and == 1//
nice. using the built in [==] makes a lot more sense than the [invert] object i was using...
suppose you have two subpatches both heavily taxing the cpu with audio-rate signal processing, but due to your switch, you only want one of them on at once. is there a way to selectively disable dsp on a subpatch basis? i saw something in the help files about a similar trick for blocksize, but perhaps i havent dug deep enough to into the scheduler code or help files to know if something like a simple toggle .x40203 DSP 0 method exists..
for this, try [switch~], which serves the function of "switch"ing on and off DSP for a subpatch. send it a toggle.
somewhere i remember seeing an abstraction which would detect when the inlet~ level is quiet and [switch~] off DSP at that time, and turn it on again when it gets more level ... i thought it was a good idea, as long as there's some envelope to avoid clicks. can't find the abstraction now though...
e
somewhere i remember seeing an abstraction which would detect when the inlet~ level is quiet and [switch~] off DSP at that time, and turn it on again when it gets more level ... i thought it was a good idea, as long as there's some envelope to avoid clicks. can't find the abstraction now though...
it's in the sigzero~ help file (zexy)
Matt
-=-=-=-=-=-=-=-=-=-=-=-=- http://www.loopit.org/ -=-=-=-=-=-=-=-=-=-=-=-=-