[linux-audio-dev] PTAF link and comments

[Tim Hockin]

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

It's not pretty, but it is useful.  LADSPA plugins in a XAP<->LADPSA
wrapper.  VST plugins in a XAP<->LADSPA wrapper.  XAP subnets in a XAP<->XAP
wrapper.

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

Yeah.  process(replacing) is easy.  Nothing extra needed.  process(mix)
NEEDS a standard WET/DRY gain pair.  I mean, I guess it can run without
them, but isn't that why people never use it in VST in the first place?

If you have a plugin with WET and DRY, but want to use it as replacing,
those values still probably have meaning, no?

Simpler is better.  Can we pass a static wet_gain and dry_gain to
run_adding() ?  Do we need a gain at all?

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

All these 'flags' may be better off as
descriptor->meta_flag(XAP_CAN_INPLACE) style stuff, rather than bitmasks.
But simpler is better.  Simpler is better.

My new mantra
Simpler is better