7 Feb
2003
7 Feb
'03
5:12 p.m.
On Friday 07 February 2003 21.14, Steve Harris wrote:
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 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...
Obviously, if it's rarely going to do any good, it shouldn't be in the
API, or it should possibly be in some optional extension that both
hosts and plugins can just ignore if they like.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
On Fri, Feb 07, 2003 at 03:22:27 +0100, David Olofson
wrote:
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.
In a perfect world, no one would clamp, ever - but I don't think it
gets that fun, unless we forget about natural units and soft ranges.
On Friday 07 February 2003 11.07, Steve Harris
wrote:
No, no. I mean doing its own clamping is a bad requirement to place
on plugins. Much of the time it wasted effort, and its just loads
of duplicated code in each plugin. On Thu, Feb 06, 2003 at 08:38:10 +0100, David
Olofson wrote:
Yes, that's exactly my point - and the motivation for having
plugins clamp input controls with hard ranges. > It sounds like the wrong thing, the general
case is that
> the host generates values its knows to be in range, then
> the plugin checks it again to check its in range...
Not the host; the *sender*. That is the sequencer (which can
be part of the host), or more interestingly, any plugin that
has control outputs.
OK, but it seems like a bad requirement to place on the plugin. 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?
Normally, you'd just:
something = ev->fcontrol.value;
Now you'd have to:
something = xap_event_get_fvalue(what?, ev);
where
static inline float xap_event_get_fvalue(XAP_what? what?,
XAP_event *ev)
{
float value = ev->value;
if(what?->needs_clamping)
{
if(value < what?->clamp_low)
value = what?->clamp_low;
else if(value > what?->clamp_high)
value = what?->clamp_high;
}
return value;
}
(Low and high limits that are soft would actually be values near - and
+ infinity, respectively, to avoid yet another level of
conditionals.)
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.
Another idea would be to require that plugins have two targets for
controls that need clamping, so the host could decide which one to
use and just get the right cookie. Plugins still need to do the
clamping, but now it doesn't impact non-clamping input, and the
clamping version gets sligtly less expensive.
Still need to figure out what that XAP_what? should be, and where
plugins should keep it. And how to motivate it's excistence...
[...[0, 1] ranges...]
All of these are a big step back from LADSPA, so
I'm ignoring them.
And regardless of what LADSPA has, I don't like these either.
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. Just as an
example, you don't run the chorus and the verses of a
pop song all in parallel, but they may (and usually do) have
totally different processing.
OK, but this is only worth anything if the tails of the verse dont
overlap with the start of the chorus at all, and that is a special
case.
In any case these kind of optimisations blow the ~constant cycles /
sample assumtion out of the water, which will make using it
reliably very hard, except in the situation where the total CPU
taken by the plugin processing is minimal compared to the rest of
the (non RT) system. I dont think thats likly to happen in XAP,
though it may in audality.