Subject: Re: [linux-audio-dev] app2app interface
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Mar 31 2000 - 15:41:57 EEST
Kai writes:
>I've been thinking about the recent "programs-as-plugins vs IPC"
>discussion, and especially, how LADSPA fits the big picture. As
>I see it, most audio apps work like this:
>
>0...n inputs --> { audio app internals } --> 0...n outputs
>
>Inputs&outputs are links to the outside world (files, soundcards, etc),
>while everything else happens inside the app. The current LADSPA
>design suits best for internal processing; simple and easily usable
>building blocks used by the host app.
>
>As for the "other plugin API", I don't see it as a competitor (or
>replacement) for LADSPA, but rather a different kind of API. It
>would be used at the "-->" -points in the above figure.
>In other words, it would be a interface for simulating IPC
>between audio apps using function callbacks - run programs
>as plugins.
Actually, I don't necessarily agree. The first VST plugins I wrote
were "alsa_input" and "alsa_output". As the exist right now, they are
pathetically simple and naive, but thats mostly because I wanted to
hack something together very quickly, and because I don't fully
understand VST hosting enough to understand certain aspects of how to
instantiate them if they were more flexible.
On the other hand, EASI (Emagic) and ASIO (Steinberg) are clearly
designed for this aspect of things, and they don't pretend to be
generic plugin API's, but specifically designed for
"drivers". I am agnostic on whether we need this kind of functionality
under Linux, because of the rather different relationship we have
between the kernel and user space. However, EASI does contain a lot of
clearly useful functionality, and seems rather well thought out.
>all. And, of course, if I had to make a plugin version of my
>standalone xxx softsynth, it's the soundcard i/o routines I'd
>have to replace with plugin callbacks.
Precisely :)
--p
This archive was generated by hypermail 2b28 : Fri Mar 31 2000 - 18:32:04 EEST