> > > 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) > > Yeah. It's always a good idea to consider alternatives, I guess we > haven't seen any sensible ones yet...
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. 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. 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? > > > 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. 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. > 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.
