Subject: Re: [linux-audio-dev] PTAF link and comments
From: Tim Hockin (thockin@hockin.org)
Date: Tue Feb 04 2003 - 22:12:51 EET
> > Yeah, but is it really that useful? Ok, VST seems to survive with the
> > same restriction, but I'm not sure if it actually solves more
> > problems than it creates.
>
> Agreed, in practice you can connect things together if you allow arbitrary
> ranges.
Well, at some point we talked about hardlimited ranges. If we have a
control that has hardlimited ranges, and you connect joe random to it, it
can go out-of-bounds and blow up. Either all controls check their own
bounds, or we have to provide scalar plugins to convert control streams, or
we normalize controls. We have a few classes of numerical value controls:
unbounded (one or both bounds are infinite)
bounded (both bounds are well-defined)
enum (a special class of bounded)
positive only
negative and positive (zero-centered, hopefully)
It's hard to normalize for all these. 0-1.0 can make sense for bounded, but
is useless for unbounded.
hrrmm..
> > Yeah, that would be reasonable, I think. In the few cases where
> > plugins can't be in-place safe (or the author is too lazy), we even
> > have a nice, cache friendly solution: The audio buffer pool. (A LIFO
> > stack of preallocated buffers. Optimized hosts will probably use one
> > anyway, instead of fixed buffers all over the net.)
>
> Hmmmm.... not convinced.
If a plugin can flag itself as in-place-safe, is that good enough? We then
push that into the host, which is OK, I guess.
> > > Well, there also needs to be a way for a plugin to wrap other
> > > formats, and change all it's metadata. I imagined that a plugin
> > > couls tell the host that it needs to be re-examined -
> > > XAP_EV_GESTALT - or something.
> >
> > Yeah.
>
> Ugh!
Better ideas welcome... We need to change the meta-data as a function of some
control. Perhaps wrappers need special attention? Add a flag that says
they are a wrapper, and a flag on the control that changes the universe?
What if it is multiple controls?
> > Yeah. run_adding() is indeed nothing but a performance hack. Question
> > is if we really need it these days. I'm not saying that we'll ever
> > have enough cycles to just waste them, but focus is shifting
> > continously. Things are getting higher level.
>
> I disagree. Its really quite expensive.
So we standardiz: if your plugin provides MIX_WET and MIX_DRY controls, the
host can use those and you assume run_adding() behavior. If you do not
provide those, you are replacing. If you want to supprt run_adding()
behavior, you need to specify those two controls (or is one percentage
control enough ?) The host still only calls run(), but if you provide
those, it can use you without a send-return loop. Is that good enough?
This is what hints are there for, after all.
Tim
This archive was generated by hypermail 2b28 : Tue Feb 04 2003 - 22:19:32 EET