4 Feb
2003
4 Feb
'03
8:42 p.m.
On Tuesday 04 February 2003 21.12, Tim Hockin wrote:
[...]
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...
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.
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. 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. 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 ---