On Sat, Mar 01, 2003 at 12:29:10AM +0100, David Olofson wrote:
> On Friday 28 February 2003 22.01, Dave Griffiths wrote:
> > On Fri, 28 Feb 2003 19:05:19 +0100
> >
> > David Olofson <[EMAIL PROTECTED]> wrote:
> > > On Friday 28 February 2003 09.20, [EMAIL PROTECTED] wrote:
> > > [...]
> > >
> > > > 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.
> >
> > 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.
>
> 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.
>
>
> > > > 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.
> >
> > 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
