21 Feb
2003
21 Feb
'03
9:10 a.m.
On Thu, Feb 06, 2003 at 10:38:22AM +0000, Steve Harris wrote:
Silence should be a hint on the buffer, and a Delay would only emit a silent
Buffer after being instantiated and not having input.
which in fact means never :)
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
On Wed, Feb 05, 2003 at 02:41:44 -0800, Tim Hockin
wrote:
This souds like a really bad idea, I think the intention of the plugin
reporting its RT60 (or whatever) tail size is for post roll, not silence
detection. Silence detection is pretty pointless in RT systems, and likly
to a huge source of bugs.
But silence detection before some delays can be ok.
Nice. Can
be used for "optimized silence", of course - which leads to
a question: How about *outputs*? Plugins that keep track of whether
or not they're actually generating audio would need a way to mark
each output as "audible" or "silent", before returning from each
process/run() call.
Yes - we have a few options here. This is something that can save MASSIVE
CPU, and is really needed.
You cant use the "free" cycles, because youre never sure when the plugin
is going to wake up and start chewing CPU again, and in any case you dont
know how much it was really using.
the free cycles can be used for faster GUI updates. i think it is useful.
Ontop of that the RT60 time is only a guideline,
depending on the
processing graph it may be totally inapropraite to assert silence after
the nominal decay time.
A Delay or similar would never emit silent buffers.
If a chain of plugins starts with a voiced
instrument, we have a clue when
there is nothing coming down the chain (instruments need to confirm it, of
course). Each plugin in the chain might eventually be silent, with silent
input. Silence needs no processing.
"Silence" is relative. A reverb will onyl decay to mathematic silence
after a really long time, but that isnt the intention of this hint IMNSHO.