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