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

[David Olofson]

On Sunday 08 December 2002 21.19, Tim Hockin wrote:
> > > Well, my first thought is that we don;t want to send a
> > > CTRL_CHANGE event to the host every time a control changes,  Do
> > > we want the host to have to send CTRL_GET events and wait for
> > > CTRL_VALUE events, or can we say 'one tick granularity is all
> > > the host can get' wrt CTRL_GET?
> >
> > If the host is marshaling the events then it should know what the
> > last controller value it sent to the instrument was.
>
> I'll buy that.  Once the host reads the initial values, it should
> refrain from bothering the plugin.
>
> Aside: Do we see a need for plugins to spontaneously change a
> control?

Interesting question...


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

Sounds like pure implementation details to me. What you do is just 
say "these controls are *target* values". In fact, most plugins in 
most APIs do this anyway, since anything else will result in clicking 
and zipper noise.


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

Sounds like a bad idea to me... You want one callback per sample, or 
some arbitrary resolution?

If you really want a plugin to tell the host (or another plugin) what 
it's doing internally, publish that through an *Output* Event Port.

I don't think there's a good reason to have controls act as both 
inputs and outputs at the same time, since you can have the exact 
same functionality with one "target" input control and one "actual 
value" output control.


> Also to think about - what if the host sends a bad value, and a
> control wants to reject it?

It can't. The host f*cked up, and the plugin may even *crash* without 
the plugin author deserving as much as a "you might want to fix this" 
email.


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

Possibly. In fact, that could be a rather nice feature for some 
stuff. (Say an enumerated integer control, where some values in the 
middle may not be valid under some circumstances.)

Anyway, that would be an *optional* feature. Plugins that just tell 
the host about the type and range of a control should not be expected 
to even range check the values they receive. (Why check data stored 
in the sequencer's data base over and over again, for example? If the 
host gets data from an untrusted source, check it before it's given 
to any plugin...)

[...]


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