7 Feb
2003
7 Feb
'03
11:37 p.m.
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. Right, but you have to put the flag somewhere. If
there's a nice place
for it,
We can ver easily turn a XAP_sample *buf into a XAP_buffer { flags, buf }
struct.
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.
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. > On thinking of it, I think Silent-per-buffer
flags are better.
I still agree with myself, which is rare after three days in this
discussion. :)
I think we have to think about the implications.
Let's look att all
combinations for starters:
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
If we make a small adjustment and say that silent buffers are zeroed (not
really THAT costly), then this is no matter at all.
Or we can just say that only the host can mark a buffer as silent. If a
plugin wants to generate silence, but the output buffer is not silent, it
better do it itself.
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.
We can also make a very simple non-optional rule that if you generate data
for an output buffer, you must clear it's silent flag. This eliminates the
need for a plugin flag indicating silence support.
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.
Yeah. Or users can beat developers of dumb plugins for wasting CPU.
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.
In my mind this was the WHOLE reason :). I might build up a very
complicated net of plugins for my track. If I tried to run all those
plugins for every process-cycle, it would never finish in time. But the
reality is that at any one time, my tracks are using maybe 35% of the whole
net. Usually less. An optimization that allows a reverb to return almost
immediately helps me to ensure I meet the deadline. I hate clicks and
drop-outs.
For live performance with XAP plugins, it is a big win.