On Mon, Mar 03, 2003 at 09:57:50AM +0100, David Olofson wrote: > On Sunday 02 March 2003 17.23, [EMAIL PROTECTED] wrote: > [...silence handling...] > > > Yeah. What's the problem? > > > > we must always call all plugins. > > i was thinking that it would be possible to stop processing() > > silent subnets. > > Well, it's just that if you stop calling process(), something else > will have to be done to decide when to start calling it again... I > suspect that that will cost significantly more than a function call > if the feature is going to be seriously usable. If a plugin does the > testing itself, there's no limit to what it can check for, and the > checking code can still be highly optimized.
yes... we agree on that.. > > > > flagging silence still provides for optimisation IN the plugins. > > Yes. > > > > > BTW, plugins that theoretically never go silent could still have > > > a user controlled silence threshold control... > > > > yes... but this is plugin implementation.. > > Yes, although it might make sense to have a standard > "SILENCE_THRESHOLD" control, so hosts can present it as a central > control for the whole net, or for a group of plugins (mixer inserts, > fo example), or whatever. Where it's not present, the host will > assume that the plugin consideres only absolute silence, provided the > plugin supports silence at all. ok ... so we are going one level up now... standard names for controls... > > > > as long as XAP defines a method to describe > > silence its ok. > > Right. We just have to make sure the supporting features are there as > well, or silence processing will just end up as some obscure and hard > to use feature that will be a major PITA for any user who need to use > it. Hosts must have enough information to be able to figure it out > for themselves, without the user messing with each plugin manually. how will the silence be indicated ? NULL is not so good for inplace processing :) is there inplace processing in XAP ? > > > [...] > > > Silence with a DC offset is not silence, IMO. Unless you're going > > > to stay on that level *forever*, it's not DC, and then it can't > > > be silence by any definition, can it? > > > > no... its "silence with a dc offset" != "silence" . effectively > > making it a constant for this next block... > > Yeah, I can see where you're going, but is it useful to assume that > silent buffers are equivalent to zeroes? > > A plugin that's optimized for silent input is not just a matter of an > alternative loop that takes hardcoded zeroes (or a fixed DC level) > instead of real data. That would hardly affect performance at all > with most algorithms. The real gain is when the tail is out and you > can stop processing completely, only generating "silent" flagged > buffers. This *can* indeed happen if the inputs stay at fixed DC > levels for extended periods of time - but how likely is that? a fixed DC of 1000 means something completely different to a frequency modulator than silence... but silence is only dcsilence(0) > > (At least in XAP, we don't use audio inputs for control data. We use > sample accurate timestamped events with linear ramping.) a frequency modulator takes audio input as i see it. even if linear ramping would be extended to polynoms and other nonlinear things it would never have the power of an audio rate control... > > > > > Either way, remember that we're dealing with blocks here. (Larger > > > time spans are pretty irrelevant from a practical POV.) If any DC > > > level is silence, is a square wave that happens to have a period > > > of exactly two blocks silence as well? ;-) > > > > no. > > example: > > block size = square_period / 2 > > > > square_phase = 0 > > > > block 1 = dcsilence(1) > > block 2 = dcsilence(-1) > > ... > > > > silence flaggin means this block only contains zeros. > > dcsilence(x) flagging means this block only contains x > > > > this is like having metadata on an audio block > > providing smart plugins with the capability to optimize their > > processing. > > Yeah, I understand that, but I don't see how plugins that use any > significant amount of cycles can make use of this. "Register instead > of stream" kind of optimizations are pretty much irrelevant for most > plugins, I think, and all the special cases it would require (one > case for every likely combination of active, silent or DC inputs) are > just not worth it. i guess you are right... but if you think this somewhat further it is a nice idea... making up a different very complex protocol it should be handled like extended ramping events... -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
