[linux-audio-dev] PTAF link and comments

David Olofson david at olofson.net
Tue Feb 4 22:47:01 UTC 2003


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




More information about the Linux-audio-dev mailing list