1 Mar
2003
1 Mar
'03
3:01 p.m.
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!?")
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...
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? ;-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---