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" <[EMAIL PROTECTED]> wrote: > On 12/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
