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

David Olofson david at olofson.net
Sun Dec 8 17:41:01 UTC 2002


On Sunday 08 December 2002 11.42, Steve Harris wrote:
> On Sat, Dec 07, 2002 at 09:52:28 -0800, Tim Hockin wrote:
> > Do we really want to have different controls for different
> > channels?  I can see how it might be neat, but since multiple
> > channels is convenient for hardware people, shouldn't we leave
> > the controls the same, too? :)
>
> Sounds sensible.

Well, I think means trouble for mixers, synths with sophisticated 
"master sections" and that kind of stuff. You want to use the same 
controls for busses as for strips?

Multiple "Channel Kinds". There will have to be multiple *types* 
anyway; something like:

	The Master Event Input Channel
	Event Input Channels
	Event Output Channels
	Audio Input Channels
	Audio Output Channels

So, why not just throw those *types* into an enum or something, and 
then let plugins have an array of something like this:

	struct SOMEAPI_channel_kind
	{
		SOMEAPI_channel_types type;	event/audio/in/out/...
		const char *name;	Name of this kind of channel
		int count_min;		min # of channels of this kind
		int count_max;		max # of channels of this kind
		...
	};

(Or maybe call them Channel Groups?)

Then you can have any number of *different kinds* of Channels. It can 
all results in a single 1D array of Channels anyway (like LADSPA 
ports), if that's desirable. (It may not be, though, as that makes it 
much harder to change the number of Channels of a certain kind 
without reinstantiating the plugin. Some plugins may not need that 
for certain kinds of Channels, so why enforce it? A 1D array 
(Groups?) of pointers to 1D arrays of Channels would be better, IMHO.)


> > > However, it might be handy for the host to be able to ask for
> > > the values of specific controllers. It may or may not be useful
> > > to do that multiple times per buffer - but if it is, you'll
> > > definitely want the timestamps of the "reply events" to match
> > > those of your request events, or things will get hairy...
> >
> > Uggh, can we keep the get() of control values simpler than
> > events?  My previos proposal had a control->get() method and a
> > ctrl->set() method. Obviously, the set() is superceded by events.
> >  Is the get, too?
>
> What is this for? If you want to implement this then they need to
> be events (well, sample accurate), but they sound like a pain to
> implement.

Trivial for the plugin to handle and reply to, but they might be 
tricky to use for anything sensible. Unless they're in the form "give 
me the values of controls A through B" (which can become a nightmare 
as soon as you even think about multiple event datatypse...), you'll 
have to *flood* a plugin with events to read it's full state... Then 
again, the same applies to function calls.

The event might actually be faster, at least if you do it by asking 
for a bunch of controls at a time, running the plugin for 0 frames 
each time, until you're done.


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