Re: [linux-audio-dev] PTAF link and comments

On Wednesday 05 February 2003 02.06, Tim Hockin wrote: [...wrappers; transforming plugins...] 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.) [...] 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.) 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... No, not unless we can pass arrays of them to address all outputs. 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. 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 ---