On Thu, Feb 06, 2003 at 10:38:22AM +0000, Steve Harris wrote: > On Wed, Feb 05, 2003 at 02:41:44 -0800, Tim Hockin wrote: > > > 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. > > 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. > > 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. 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
