1 Mar
2003
1 Mar
'03
1:53 p.m.
On Sat, Mar 01, 2003 at 12:29:10AM +0100, David Olofson wrote:
I must admit I haven't followed this discussion too closely, so
you've probably covered all this before, but I think all this work
to figure out if you are processing silent data is not really as
much a win to be worth the hassle - as it won't ever make the worst
case faster.
There isn't much work at all, really. Still, it's complexity, and it
has to be motivated. IMNSHO, determinism is *not* a valid reason to
avoid silence support, but handling large nets where only part of the
net will run at any time, and using the leftover CPU time for other
stuff (GUI, for example) are two reasons to have it. I don't think
we've decided anything, so I guess it all depends on whether or not
it can be prooven useful enough to motivate it's existence.
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)
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.
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-)
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
On Friday 28 February 2003 22.01, Dave Griffiths
wrote:
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.
On Fri, 28 Feb 2003 19:05:19 +0100
David Olofson <david(a)olofson.net> 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. On Friday 28 February 2003 09.20, torbenh(a)gmx.de
wrote:
[...]
In ssm I sort the network each time a connection is made/destroyed,
and generate a ordered list of modules to process from the root up
to the leaves. It has to cope with circular sections, which
unavoidably introduce latency, but it works. It also automatically
means unconnected modules don't get processed, which is nice. random latency ? how do you mean that ?
Latency depends on how you happen to construct the net (order of
instantiation, connections etc) and/or the actual layout of the
net, in "non-obvious" ways. see current implementation...
[...]
one advantage is with silent sub nets....
I'm not sure it's that easy. What about plugins with tails and/or
internal state? (Delay, reverbs, most filters, ...) You can't
just stopp running these when they get no input, or when you
don't need their output.