7 Feb
2003
7 Feb
'03
10:14 p.m.
On Saturday 08 February 2003 02.17, Tim Hockin wrote:
[...]
I think it can come almost free. Plugins that don't optimize, do
nothing. Plugins that want to optimize do an extra flag check. Not
too hard.
Right, but you have to put the flag somewhere. If there's a nice place
for it,
Yeah, you're right... Effects *generally* don't start making sound
just becaues you change some parameter, though - but that's the only
way this could work at all.
You need an explicit "run without processing audio" mode for this.
Assuming we really want to allow soft-limits (which I
just don't
get), we can just say that if you want a hardlimit, constrain it
internally.
Yeah.
As to soft limits, I think the main point is to relieve the plugin
author of the task of figuring out the absolute minimum and maximum
control values that could possibly generate any interesting results,
so he/she doesn't have to release a modified plugin under a different
major version number later on, just to extent some control ranges.
If you can't decide on the "useful" range, just throw something
reasonable into the range hints, and clamp to some bigger range that
you know is technically safe for the algorithm. If users want to look
for cool effects outside the "official" ranges, they can, and
although plugins might produce evil noises (which some actually might
find useful), they won't crash or anything like that.
I'm all for optimizations, but really, this is a
MICRO MICRO MICRO
MICRO optimization. SOMEONE SOMEWHERE is going to do a conditional
and constrain. Be it the host or the plugin.
Yes. The only exceptions would be when you have a hard limited output
that's within the range of a hard limited input, and when you have
prerecorded data. However, the latter case only applies if you assume
that recorded data will be destructively processed whenever you
connect something. *heh*
Let's just say that all ranges are suggestions,
and if it matters,
it is the plugin's problem. If we later find this to be a big
problem, we'll deal with it. Fair?
Yeah. Works for LADSPA, so it can't be *that* bad.
> I do see your point, but I'm not certain
whether or not this
> optimization is really useless for normal "one song at a
> time" use. Some real life test data would be really
> interesting...
Yeah, that's one of the reasons why I can't quite make up my mind
on this. This feature is not for free, so it has to be seriously
motivated. Besides, if you have seriously heavy plugins in
combination with
this "a few effects at a time" behavior, the host could probably
optimize this a bit without plugins explicitly supporting it. It
means the host has to test buffers and figure out a clean way of
activating and deactivating plugins without side effects, but if
the plugins, or whole sub nets of plugins can be disabled, it's
still a big win. ...and doesn't require any API support
whatsoever, apart from the (de)activation stuff, which is needed
anyway.
This was more or less what I originally proposed. If a plugin can
indicate that it will not do anything unless more (non-zero) signal
turns up, it can be virtually removed from the tree. Except it
still needs to run() for events. On thinking of it, I think Silent-per-buffer flags are
better.
Yes. The alternative would be some other, closely related but much
less obvious feature... And then we might as well do it properly. Or
not at all.
I think we have to think about the implications. Let's look att all
combinations for starters:
0) Silent buffers; host: NO, plugin: NO
No problem. No one will check the flags,
and all buffers will contain valid data.
The host SDK would clear the "silent"
flags when initializing the buffer
structs.
1) Silent buffers; host: NO, plugin: YES
This will not work, since a plugin with
silence support may leave garbage in
silent output buffers. The host must
check and clear such buffers before
they are fed to plugins w/o silence
support.
2) Silent buffers; host: YES, plugin: NO
No problem. There will be no silence for
the host to deal with.
3) Silent buffers; host: YES, plugin: YES
No problem. Whenever a plugin without
silence support is to be called, the
host will check and clear any silent
buffers on the plugin's inputs. The
host will also reset the "silent"
flags of all outputs from the plugins,
since the plugin will always generate
valid output, but not touch the flags.
Now, there is a problem here: If you have a chain of plugins, and some
of them don't support silence, these will screw things up for the
silence aware plugins. However, if we apply silence detectors on the
outputs of plugins w/o silence support whenever they're sending to
plugins *with* silence support, things will work fine.
Any other aspects?
And of course, regardless of how complicated or simple this is, it has
to be sufficiently motivated.
One thing I haven't really considered before (in the DAW context), is
that any CPU time you save in the DSP thread reduces the risk of
drop-outs in a "firm" or soft real time system, and maybe more
importantly (to people with real operating systems ;-), it is extra
CPU power for disk butlers and other high latency background
processes.
I don't think this is insignificant, *especially* not if XAP is
supposed to go anywhere outside Linux/lowlatency or other
"practically hard real time" platforms.
//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://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---