> > 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.
Unless anyone objects with good arguments, I'm putting it in my notes as such. > 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. Except that they MIGHT audibly respond to a control. Unless the host knows EVERY event sent, we have to run it as normal. > > 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.