7 Feb
2003
7 Feb
'03
6:15 p.m.
On Fri, Feb 07, 2003 at 10:04:54 +0100, David Olofson wrote:
Yeah, it would still suck.
It sounds rather fine to me, but if me *really* don't want plugin code
to contain explicit clamping, ever, I guess we could figure 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)
[silence optimisation]
Yeah, that's nasty as well - but not nearly as
nasty as forcing
*outputs* to clamp to the range of whatever inputs you connect them
to.
Sure.
Maybe the host
could signal that a control might go out of range
and the SDK could do the checking? Thast ways its transdparent to
the plugin.
It would require rather a rather high level wrapper for controls,
meaning you can't just read your values from the event struct.
*That's* perhaps not much of a problem, but how to implement it? if(what?->needs_clamping)
{
if(value < what?->clamp_low)
value = what?->clamp_low;
else if(value > what?->clamp_high)
value = what?->clamp_high;
}
...
You might ove the conditionals around a bit depending
on which case
you want to be the fastest, but I don't think it gets much more fun
than that.
The are branchless clamps, which save a few cycles.
4) Controls have plugin defined hard ranges.
* Either all plugins clamp their inputs, or
hosts snoop all connections.
5) Controls have plugin defined soft ranges.
* Plugins that actually have hard ranges
must clamp internally.
This is what we have in LADSPA. The hard ranges are not expressed
to the host, and they probably dont need to be. 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...
You also have to weigh the cost of increased debugging dificulty, and the
erros when lugins mis-estimate thier silence state.
- Steve