Subject: Re: [linux-audio-dev] XAP spec & PTAF comments [merge]
From: David Olofson (david@olofson.net)
Date: Fri Feb 07 2003 - 23:04:54 EET
On Friday 07 February 2003 21.14, Steve Harris wrote:
> On Fri, Feb 07, 2003 at 03:22:27 +0100, David Olofson wrote:
> > On Friday 07 February 2003 11.07, Steve Harris wrote:
> > > On Thu, Feb 06, 2003 at 08:38:10 +0100, David Olofson wrote:
> > > > > 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.
> >
> > Yes, that's exactly my point - and the motivation for having
> > plugins clamp input controls with hard ranges.
>
> 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.
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.
> 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.
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.
[...]
> > 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.
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 ---
This archive was generated by hypermail 2b28 : Fri Feb 07 2003 - 23:14:04 EET