Any Ideas for how to halt or enable passage of info through sig and
control
patch cords? not a necessary question but would be helpful k
spigot?
Well, [spigot~] maybe. But here's a deeper question... because I would choose a simple [*~] with a zero or one to gate on and off the audio stream.
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?
ANdy
steve
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
2006/12/30, padawan12@obiwannabe.co.uk padawan12@obiwannabe.co.uk:
Well, [spigot~] maybe. But here's a deeper question... because I would choose a simple [*~] with a zero or one to gate on and off the audio stream.
Isn't nullification a bit rough for the audio stream? Perhaps, ramping down would make a more appropriate solution in the case?
Common practice is to use:
[osc~] (audio source) | | [x] (toggle, numeric message, 0/1, etc) | | | [pack 0 50] (change second number for longer ramping) | | | [line~] | | [*~]
d.
Denis Trapeznikoff wrote:
2006/12/30, padawan12@obiwannabe.co.uk mailto:padawan12@obiwannabe.co.uk <padawan12@obiwannabe.co.uk mailto:padawan12@obiwannabe.co.uk>:
Well, [spigot~] maybe. But here's a deeper question... because I would choose a simple [*~] with a zero or one to gate on and off the audio stream.Isn't nullification a bit rough for the audio stream? Perhaps, ramping down would make a more appropriate solution in the case?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Denis Trapeznikoff wrote:
Isn't nullification a bit rough for the audio stream? Perhaps, ramping down would make a more appropriate solution in the case?
i do not see how you get your definition of "the" case. without that, one really cannot say whether ramping or not is the "more appropriate" solution.
however, to find appropriate solutions it is always good to have a choice of several, e.g. without ramps, with linear ramps, with...
fgma.sdr IOhannes
2007/1/16, IOhannes m zmoelnig zmoelnig@iem.at:
i do not see how you get your definition of "the" case.
"The case" should be read as "the case of audio stream", and the word "audio" made me assume that somebody could hear the stream. Of course, generally, any non-sporadical stream of data could be considered, if not mention the audio stream itself could be inaudible...
On 1/29/07, Denis Trapeznikoff denissimo@gmail.com wrote:
2007/1/16, IOhannes m zmoelnig zmoelnig@iem.at:
i do not see how you get your definition of "the" case.
"The case" should be read as "the case of audio stream", and the word "audio" made me assume that somebody could hear the stream. Of course, generally, any non-sporadical stream of data could be considered, if not mention the audio stream itself could be inaudible...
The audio stream could be modulating another audio stream, that might not be affected by sudden cutoff.
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
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
-
Chuckk Hubbard -
Denis Trapeznikoff -
Derek Holzer -
IOhannes m zmoelnig -
padawan12 -
padawan12＠obiwannabe.co.uk