Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: David Olofson (david_AT_olofson.net)
Date: Mon Dec 09 2002 - 02:25:24 EET
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 ---
This archive was generated by hypermail 2b28 : Mon Dec 09 2002 - 02:34:18 EET