[PD] sig/control on/off
padawan12 at obiwannabe.co.uk
Tue Jan 30 14:36:08 CET 2007
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 at gmail.com> wrote:
> On 12/30/06, padawan12 at obiwannabe.co.uk <padawan12 at 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?
More information about the Pd-list