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