Subject: Re: [linux-audio-dev] Ideas for AES/LAAGA/whatever (was Re: sound API libraries, servers, etc.)
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Thu Apr 26 2001 - 00:29:57 EEST
Paul Davis wrote:
> you need to understand the the plugin standard being discussed is
> nothing like LADSPA (or VST). its not a way of connecting together DSP
> units that do small well-defined jobs. its a way of gluing together
> entire applications so that they can share devices and more
> importantly their own data. the comparison in the win-macos world is
> steinberg's ReWire, something entirely separate from VST.
I can't see it as terribly different. I was following the progress of
the new Amiga for some time, and their adopted OS: Tao's Elate (they
now appear to have changed direction and temporarily gone back to a
PPC-enhanced AmigaOS, for some strange reason). Elate is a completely
plugin-based OS - every function in your program is an
independently-loadable module (`tool' in their jargon). There is one
memory space, and there are no boundaries between processes. You can
even arrange to have call-backs to your functions on your data from
another process !! This is one wide-open plugin arena !
Now then, as an exercise, try thinking in this space instead of the
standard UNIX space (i.e. of processes with rigid boundaries, and a
preference for monolithic executables and shared libraries -
monolithic on Elate's scale, at least). It's quite interesting how
things change - and how things seem more do-able when mapped back to
Linux again (well, it was a revelation to me at least).
Now, based on something like Elate, what difference is there between
connecting big applications together and connecting small plugins
together ? In the main processing loop that you describe, the
`server' is still calling the shots, asking each plugin to process X
samples of data. I can't see the difference at this level.
What is additional, it seems to me, is that these applications will be
requesting to be connected this way or that way, rather than being
completely under the control of the `server'. However this is an
additional level which can be made independent of the main loop of
sample processing. The main loop is very similar if not identical to
a LADSPA main loop.
We could (in theory) implement something like what you describe by
taking LADSPA, and then making a specification for a special kind of
LADSPA server that accepts commands from applications wishing to be
connected up in a particular way.
Not that I'm necessarily suggesting this is the way to go - just to
point out the possibilities as an aid to thinking around the issue.
...
Let me push the boundaries out a little further. Okay, there will be
some applications that just want to be connected up, and that's the
end of it. However, if we allow a string-based command-port, then for
small simple plugins, this amounts to some kind of extra control
feature. However, for big applications, this amounts to a scripting
port (like ARexx on the Amiga). This is why I can't see the
difference between small plugins and big plugins.
If, in addition, the top-level GUI control surfaces for small plugins
generate either control-port data streams (32-bit floats) or
command-strings, and these are relayed to the `server' which relays
them to the plugin, then the `server' is in an excellent position to
record these changes. This is something like this MIDI setup:
MIDI master KB -> sequencer -> Sound module
For a big application that is connected up as a plugin, it probably
has its own GUI and all the rest. So it could talk to its plugin
directly. However, if it is kind enough to also send this data out in
the form of control data and command strings, then the sequencer can
record these as well.
This is like a well-behaved MIDI synth, that repeats all the
controller changes on the MIDI OUT, so that it can all be sequenced
properly. Less friendly gear does not repeat everything on the MIDI
OUT, and you have to fiddle around manually to recreate the original
effect (if you can do it at all).
So, if big apps can act like good citizens in this kind of setup, then
all their changes can be sequenced as well.
This means that the `server' now has several possible roles:
- It runs the main loop for the plugins
- It accepts requests from applications to get themselves connected or
disconnected to/from the various busses (as you describe).
- It passes through control data and command strings from GUI elements
to the plugins they are assigned to. It also informs GUI elements
about changes sent to plugins so that they can be up to date.
- It allows a sequencer application to connect into this and monitor
all the control data flowing around, so that it can all be recorded
and replayed.
- It accepts commands from a sequencer, from the big apps, or from
another control program to set up networks of smaller plugins as
necessary.
Is this sounding too complex ... ? I don't think it amounts to that
huge a deal. All we're dealing with is routing three types of data:
audio, control and commands. Control data and commands sent to a
plugin are also routed to the GUI (if it has one), and to the
sequencer (if one is connected). Both the GUI and sequencer need to
be able to send commands and control data to a plugin - probably the
sequencer gets priority whilst replaying, unless some sequencer or GUI
flag is set to `record' for that plugin (like "RECORD READY" on a
mixing desk).
Well, okay, it *is* rather a big picture - maybe my `master plan',
dream setup or whatever. Maybe you're talking about a small step, and
I'm talking about a huge step, but, well, maybe these ideas can help a
bit.
> all true, but: (1) how does something decide that there is silence to
> begin with and (2) this is too detailed to act as inter-application
> glue IMHO.
See my other posting about my reasons for having special handling of
silence.
> >- Upgradable control inputs. Control inputs often have constant
>
> these play no part in this kind of plugin system. Thats more like
> LADSPA which is intended to support DSP plugins. This "standard" is
> not - its just connecting applications that do audio stuff.
Oops ... I'm not too good at seeing the small picture.
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Thu Apr 26 2001 - 01:03:55 EEST