2 Mar
2003
2 Mar
'03
4:06 p.m.
On Sat, Mar 01, 2003 at 07:52:51PM +0100, David Olofson wrote:
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.
no... its "silence with a dc offset" != "silence" . effectively making
it a constant
for this next block...
On Saturday 01 March 2003 15.13, torbenh(a)gmx.de
wrote:
[...]
...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...
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. 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?
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?
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