[linux-audio-dev] PTAF link and comments

Tim Hockin thockin at hockin.org
Tue Feb 4 15:25:00 UTC 2003


> > 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



More information about the Linux-audio-dev mailing list