Subject: Re: [linux-audio-dev] PTAF link and comments
From: David Olofson (david@olofson.net)
Date: Wed Feb 05 2003 - 05:39:35 EET
On Wednesday 05 February 2003 02.06, Tim Hockin wrote:
[...wrappers; transforming plugins...]
> 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.
Yeah, I can't deny that - but I can't think of any totally clean
solution ATM. Brainstorm dump follows...
One problem is that it's normally the host that manages connections...
But physically, looking at what's going on between connected plugins,
it's just events stamped with cookies flying from one plugin to the
other. If an input "disappears" in the middle of a block, all you
have to ensure is that a few more events for that input won't crash
the plugin or anything; they should just be ignored.
As to getting the sender to STFU ASAP, it doesn't really matter to the
sender who disconnects when, or why. All you're supposed to do as a
sender is stop sending events on that output, which physically means
you clear the corresponding XAP_target struct (which contains a queue
pointer and a cookie for addressing), and whatever internal fiddling
you might want to do to avoid checking that XAP_target every time
something happens with the output. (Many senders will probably be
able to disable larger sections of output generation code when
outputs are disconnected.)
So, technically, just tell the host to disconnect whatever is
connected to the inputs you've removed, and then get on with your
business. You'll have to make sure you can handle events for missing
inputs properly, but if you're implementing a plugin that can
"transform" dynamically, this is probably no match for your skill
level. :-)
Is there anything more to it? (Except obviously that you have to tell
someone that something happened, so someone can do something useful
about it. That is, yell "Help!!! I just mutated!" high enough for the
host to hear you.)
[...]
> 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?
Yep, that's why - although I think it's rather useful even with only
the WET control. (Which would correspond to LADSPA's gain control for
that run_adding() call.)
> If you have a plugin with WET and DRY, but want to use it as
> replacing, those values still probably have meaning, no?
WET would be a plain output gain control, and DRY would either
implicitly be assumed to be 0 or explicitly be set to 0, depending on
the rest of the API. If you have a specific call or similar, the DRY
control would just be ignored, as the plugin wouldn't support
anything but plain overwriting the output buffers with it's output.
Oh, there's one thing to keep in mind: You need one gain control (or
pair of them) per output, or it won't be all that cool in real
life...
> Simpler is better. Can we pass a static wet_gain and dry_gain to
> run_adding() ?
No, not unless we can pass arrays of them to address all outputs.
> Do we need a gain at all?
Yes, one for the plugin's output signal at least. (The one we have in
LADSPA, and the one that breaks VST by being absent.)
The reason why the one for scaling the old buffer contents is slightly
less interesting is that you can fake it in the host by simply
scaling the buffers before running the plugin. To fake the output
gain control, you'd either have to use an extra buffer, or scale the
buffers both before and after running the plugin.
> > 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.
Yeah. Whatever is easiest for plugin authors, and fits the (rest of
the) bill.
//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 ---
This archive was generated by hypermail 2b28 : Wed Feb 05 2003 - 05:39:07 EET