7 Feb
2003
7 Feb
'03
9:29 p.m.
something out... It just seems to me that plugins have
a better
idea how to clamp - and they can quite often use constant limits
as well, I guess.
I'm fine with this. If the plugin can constrian the inputs itseelf,
it seems reasonable not to have explict host support. We know it
works, and its Simple(TM) > 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.