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