3 Mar
2003
3 Mar
'03
6:33 a.m.
On Mon, Mar 03, 2003 at 09:57:50AM +0100, David Olofson wrote:
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...
how will the silence be indicated ?
NULL is not so good for inplace processing :)
is there inplace processing in XAP ?
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
On Sunday 02 March 2003 17.23, torbenh(a)gmx.de wrote:
[...silence handling...]
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..
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.
Yes.
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.
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.
[...]
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)
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...
(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.