That's what I'd assumed too, and a little test with [unsig~], [env~] or [snapshot~] shows there are still empty (zero filled) blocks passed.
Or, in other words, you can only reduce CPU usage in a chain by explicit use of [switch~] to turn of DSP computation in subpatches and abstractions.
And I guess that's the correct behaviour you want if you think about it. Having it behave like tri-state logic with a "disconnected" state seems appealing for a moment, but it would make things unpleasantly complicated.
On Mon, 29 Jan 2007 15:26:56 -0500 "Chuckk Hubbard" badmuthahubbard@gmail.com wrote:
On 12/30/06, padawan12@obiwannabe.co.uk padawan12@obiwannabe.co.uk wrote:
But what is actually happening there is not the same as disconnecting or "halting" the signal. If you created a subpatch with an inlet~, outlet~ and a [switch~] unit controllable from above the subpatch how does that compare to [spigot~]? I mean - are audio blocks no longer passed to connected objects beyond the "break"? Is there any significant computational advantage to disconnecting rather than zeroing audio blocks in a typical patch?
I would think it would be like any other audio~ object with no input or parameters, equivalent to sig~ 0?
-Chuckk