[linux-audio-dev] PTAF link and comments

David Olofson david at olofson.net
Tue Feb 4 19:43:01 UTC 2003


On Tuesday 04 February 2003 21.12, Tim Hockin wrote:
[...]
> > > > 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?

*Now* I actually get what you're talking about. ;-)

Audiality running as a XAP plugin would be a typical example, as it 
has a modular mixer section that runs FX plugins. (Currently only the 
internal "stages", one of which hosts plugins using Audiality's 
internal FX plugin API. LADSPA hosting stages are on the TODO.)

Anyway, it's even more hairy than it may look at first. Not only does 
the plugin change appearance when you fiddle with certain controls; 
that may also result in *connected* controls disappearin in thin air!

Obviously not much of an issue when you're controlling it all with 
MIDI NRPNs, but if we have actuall *connections*, it gets nasty...


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

Yes, the case where you scale only your own output and add to the 
buffer is very useful as well. It's what the last plugin in every 
insert chain in a traditional virtual mixer would do, for example.


> The host still
> only calls run(), but if you provide those, it can use you without
> a send-return loop.  Is that good enough?

Sounds ok to me, although it doesn't allow for much flexibility for 
plugins that want to make use of this. For example, you can't have a 
hardcoded replacing version unless you also have the full "scale both 
old and output" version.

Why? Because you need to support the MIX_DRY control to be able to 
tell when the host wants you to do pure replace processing.


I'm thinking about "CAN_<feature>" style hints, some enum control and 
stuff, but no good ideas so far...


> This is what hints are there for, after all.

Yes!


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




More information about the Linux-audio-dev mailing list