Subject: [linux-audio-dev] LADSPA & MuCoS, The Two Models. (was: LADSPA::runAdding() )
From: David Olofson (david_AT_gardena.net)
Date: Sat Apr 01 2000 - 22:09:29 EEST
On Fri, 31 Mar 2000, Juhana Sadeharju wrote:
> How about a disk recorder plug-in which upon button press saves
> previous 10 seconds to disk and all upcoming audio. This is handy
> if you miss the beginning.
Speaking of which; an (audio) sequencer that does this all the time
would be pretty handy when jamming away - the best things are always
the ones you play or sing with the record switch off... *hehe*
> I think the point is that a plug-in can read input while not outputting
> anything. And can output more than is read for a given time-period.
This sounds like something that's way beyond the scope of LADSPA. Not
that it's incrediby complicated or shouldn't be in a plugin API, but
it doesn't fit with the audio streaming model of LADSPA, VST and the
like.
> All these can be circumvented by making the host to do them, but that
> is sort of moving the problem to later.
Yep. And forcing hosts to have all kinds of functionality, and still
forcing users to either hack their favorite hosts, or use different
hosts for not too different tasks. If that kind of functionality can
be pluggable, a lot of trouble is avoided in the long run.
> What I want is that I can
> build a working system from plug-ins alone -- like building something
> from Lego bricks without a need to mold even the base block for my
> building.
Exactly the way I see it. :-) *This* is probably the API style
classification we should be looking for:
Model 1
-------
For some jobs, plugins should be very simple units that can be
plugged into a program that can do a lot without any plugins at all.
This is the "Unit Generator Plugin" style. This requires a fast and
simple plugin API, as the plugins will usually be small and simple.
Not much flexibility is required from the API, but it has to be fast
and allow the host to do things very much the way it wants.
Model 2
-------
In other situations, you're building an entire system from plugins,
rather than extending a working system. The host is basically a
scheduler or kernel, which loads, connects and runs plugins. Plugins
are more similar to tasks in a cooperative multitasking OS than to
Model 1 Plugins, and the emphasis is on *plugins* to be able to do
things the way they like, rather than leaving everything but the
processing to the host. A very flexible API is required for this
model. As a timestamped event system may be used as an alternative
to very small buffers (ie lots of function call overhead) for high
timing accuracy, the API doesn't have to be quite as fast as for
Model 1.
Comments? Additional characteristics of these two models?
I'd say we should sort this out and design one API for each model,
rather than wasting more time trying to merge mutually exclusive
designs into one. Hopefully 2 models are enough.
As for overlap and compatibility between the APIs, it seems to me
that Model 1 plugins wrap nicely inside Model 2 plugins. This is
pretty much the idea we had from the start, but now we have some more
real experience indicating that this is the way to go, and *why*.
The only thing that still worries me slightly is how Model 1 plugins
should be wrapped inside Model 2 plugins.
Obviously, one way is to wrap an entire Model 1 host inside a Model
2 plugin. This is suitable for plugging a softsynth into a complete
virtual studio setup, for example.
Another way is to wrap *one* Model 1 plugin inside a Model 2 wrapper,
just to eliminate the need for hosts that can host both models.
(That's more complicated than it seems at first sight, I think...
It'll probably end up looking like a Model 2(Model 1) wrapper
anyway.) In turn, there are two ways to do that; a) on the source
level (recompile with wrapper headers), and b) write a generic
wrapper plugin that plugs into a Model 2 host and loads a Model 1
plugin. Both are needed, but I think it's important to keep in mind
that method a) should preferably be possible to do without a major
rewrite of the plugins. It may not be all that much code to edit, but
there is still more to it than the API and the code. (Just look at
the comments in the LADSPA header to see what I mean.)
As an example of the kind of problems I'm thinking about; how does a
Model 2 (MuCoS) wrapper know when the Model 1 plugin (LADSPA) has
changed a control output port? A MuCoS plugin would send a
timestamped event as a natural result of some condition detected
during the processing, and then forget about it, but now, the wrapper
has to add another test for every single control output.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sun Apr 02 2000 - 02:17:22 EEST