On Sat, Feb 08, 2003 at 12:03:01PM -0800, Tim Hockin wrote:
hi... first i want to apologize for not taking part in this
discussion so far. But i had a huge workload at university
and did not even have the time to read the XAP threads...
But now the semester is over and i hope to be useful to
the XAP discussions.
Branching to
fill your delay line with explit 0.0's intead of reading them
from a buffer of zeros doesn't help. We allready know that reverbs cant
support it at all. Efficieny reasons would also rule out flangers, delays,
most filters and choruses.
Maybe I'm missing something, but how can a test that amounts to this NOT be
faster than doing any work at all?
if (me->silent && XAP_BUF_SILENT(me->in[0]) &&
XAP_BUF_SILENT(me->in[1])) {
return;
}
in galan the audio inputs are obtained by calling
gen_read_input( bla bla )
which returns false if there is no connection
to the port, and also a gain set to zero returns false.
this way silent subnets are not traversed.
This method of course does not fit the
"traverse graph once and call process() in the right order"
method of doing thigs.
But if there was a method one plugin could flag that
the subnet on its input does not need to be traversed
it would scale i think.
Problems are of course:
voice -> delay -> gain(0) -> output
and then sliding the gain up...
this has to be flagged also...
hmm.. this relativates the proposal... at least consider it
a thought.
I would never, ever use a silence detecting
system live, you never
know when its going to suddenly wake up all the plugins and run out of CPU
power.
All it would take was a bit of unexpected noise on an input line and
suddenly the CPU load goes up 300%.
You may be right for a lot of cases, but there are cases where a live
performance is nothing but on the fly loop-layering, or pattern-based
sequencing. No live input, no accidentally triggering an otherwise silent
subnet. In fact, large portions of the tree would be muted at any one time
in the host.
Whether it makes sense or is a good idea, people are doing it now. And I
have a penchant for faster computers.
As for the 'feature' - let's keep it in mind, and we'll see how it
fares.
If it is not effective, or the burden is really too much, we'll scrap it.
That is why discussions like this are so great.
The method galan takes seems to work ok. It would be more work for the process()
model.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language