[linux-audio-dev] Plugin APIs (again)

David Olofson david at olofson.net
Sun Dec 8 19:31:01 UTC 2002


On Sunday 08 December 2002 22.59, Steve Harris wrote:
> On Sun, Dec 08, 2002 at 12:19:06PM -0800, Tim Hockin wrote:
> > I'll buy that.  Once the host reads the initial values, it should
> > refrain from bothering the plugin.
>
> I think the host should be able to give the instrument its initial
> values, read for deafults, or a settings file etc.

Defaults should be part of the control description, just like with 
LADSPA ports, IMO. And why is reading controls for saving to a file 
different from the usual "remember what you say to the plugin"?


> > Aside: Do we see a need for plugins to spontaneously change a
> > control?  What of a plugin that has a velocity-capped control
> > (you turn a knob fast, and it eventually gets there) or something
> > that crossfades between two values automatically.  Do we need to
> > send CTRL_CHANGE events to the host, or should we do a 'watcher'
> > callback.  Watchers is how AudioUnits works.  I don't really like
> > it.
>
> I'm afraid I'm not familar with the AudioUnits API, but I
> dont/think/ this situation requires the instrument to inform the
> host, it should just be able to damp (slew rate limit) the control,
> shouldn't it?

That, and/or there should be ramp events. Those can be a bit hairy to 
deal with at times, but please, do suggest an alternative if there is 
one that is simpler and still sufficient for sample accurate 
control... (No, no audio rate "raw" control ports, please!)


> The result from playing back automation data will be
> the same, so no harm done.

Yes, that's a good point. You're using the same plugin every time, 
right? And the plugin is what defines the exact details of what a 
control actually does. (If you want to know what it does internally, 
read the code! :-)


> > Also to think about - what if the host sends a bad value, and a
> > control wants to reject it?  Ahh, asyncronicity.  I guess for
> > this case the plugin sends back some FAIL event or simpler sends
> > back a CTRL_CHANGE with the old value (or the min/max if the host
> > has gone too far).
>
> Bad value? LADSPA has the concept that there are no bad values, the
> plugin has to accept anything. It can choose to ignore it, but it
> mustn't segfault or whatever.

Well, I'd prefer plugins being able to say whether their control 
ranges are hard, or just recommendations - and when they're hard, 
expect out-of-range values to cause the plugin to crash, div-by-zero 
or whatever!


> This is not necceserily the right thing, but it does make some
> things simpler. I'm not aware of any situations where this has
> required the plugin to tell the user "that was a crap value",
> usually the wideband distortion is hint enough ;)

*lol*
Yeah.


> In practice most hosts only send values within the range hints.

IMHO, in the new API, no host should *ever* use an out-of-range value 
when dealing with hard ranges. So, ranges *may* be hints, but if 
they're *hard*, they're much more than hints.


> > Just out of curiosity, where are you located physically, in the
> > real world? Our timezones are certainly not in sync.
>
> England, UK. GMT+1. I'm not a mornings person though ;)

Dito, except that I'm in Sweden. :-)


//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 -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list