2007/1/16, IOhannes m zmoelnig [EMAIL PROTECTED]:
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
On 1/29/07, Denis Trapeznikoff [EMAIL PROTECTED] wrote:
2007/1/16, IOhannes m zmoelnig [EMAIL PROTECTED]:
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
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
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
2006/12/30, [EMAIL PROTECTED] [EMAIL PROTECTED]:
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
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, [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
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
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
Check out the new AOL. Most comprehensive set of free safety and security
tools,
spigot
-Original Message-
From: [EMAIL PROTECTED]
To: pd-list@iem.at
Sent: Sat, 30 Dec 2006 12:30 PM
Subject: [PD] sig/control on/off
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
Check
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?
steve
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
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
11 matches
Mail list logo
