On Sat, Mar 01, 2003 at 07:52:51PM +0100, David Olofson wrote: > On Saturday 01 March 2003 15.13, [EMAIL PROTECTED] wrote: > [...] > > > Yeah, that makes sense, and I think that's the way most XAP hosts > > > would do it. I don't like the idea of leaving the insertion of > > > the (real or implicit) "delay element" in loops to the host, but > > > that's a host implementation/UI issue entirely. Plugins just > > > happily chew their audio and events one block at a time. > > > > ok... so the host must detect cycles and either warn the user he > > built something, thats not going to work like he thought or > > find a smart point where a delay can be inserted. > > ...or ask the user where the delay should be inserted, and then > present it as an actual plugin. Then the user could tune the delay. I > wouldn't want to leave that to the host configuration, as that can > screw your effects up in non-obvious ways. I don't think users should > be allowed to do this kind of stuff without at least being informed > that it has potential issues. (Who wants their inboxes filled with > questions like "Why does it sound funny all of a sudden!?")
ok... host implementation... > > > > i am fine with the first only... but this does not change the > > API... so its irrelevant. > > Right. > > > [...silence handling...] > > lets assume that silence detection is not possible for iir filters. > > -> iir filter never emits silence. > > > > this means we have to call all plugins in "silent" subnets. > > (at least if we dont have a method for the plugin to tell > > the graph traversal we are never silent... but this is out of > > scope for now) > > Yeah. What's the problem? we must always call all plugins. i was thinking that it would be possible to stop processing() silent subnets. flagging silence still provides for optimisation IN the plugins. > > BTW, plugins that theoretically never go silent could still have a > user controlled silence threshold control... yes... but this is plugin implementation.. as long as XAP defines a method to describe silence its ok. > > > a gain set to zero knows it emits silence... > > and a sample player not playing a sample knows > > this also... > > > > when silence is a flag of an audio buffer at least some > > plugins could optimize their behaviour and the mixing of > > n:1 connections would get faster... > > > > i dont think it is much hassle > > remember its not about silence detection its about silence > > flagging. > > Right. > > > > but david is of course right: this does not improve the worst case > > at all. > > > > i think its worth it... > > > > > > just thinking this a little futher: > > > > silence with a DC offset :-) > > > > d( silence with a DC offset ) > > ----------------------------- = silence > > dt > > > > int( silence with a DC offset ) = ramp > > > > well this leads to symbolic audio processing 8-) > > 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... > > 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. -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
