Subject: RE: [linux-audio-dev] A new audio plugin API ?
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Tue May 14 2002 - 00:22:29 EEST
> -----Original Message-----
> From: linux-audio-dev-admin_AT_music.columbia.edu
> [mailto:linux-audio-dev-admin_AT_music.columbia.edu]On Behalf Of Dr.
> Matthias Nagorni
> Sent: 13 May 2002 10:53
> To: linux-audio-dev_AT_music.columbia.edu
> Subject: [linux-audio-dev] A new audio plugin API ?
[...]
> So I would expect that if you can use an audio plugin API to implement
> modules for a modular synthesizer, this API should provide enough
> functionality for (almost) all other audio applications you can think of.
> The invention of voltage controlled modules, made popular by Moog in the
> sixties, has had an enormous impact on the development of electronic
> music. Learning from this will lead us to the most important item for
> LADSPA extension, namely dynamic control ports that accept arrays.
> Once a new plugin API is implemented, it would be possible to
> implement all
> the modules of a modular synthesizer as plugins. This way, softsynths
[...]
Yep, this is important stuff. LADSPA was designed from ground up for modular
synthesis, however I had a different approach in mind, part of which I
implemented before starting my (rather demanding) current job. There wasn't
much point continuing as there are such excellent LADSPA-friendly synths out
there already. But just because I find it interesting there are notes
below...
> Now the wishlist:
>
> 1) Default values
On its way for LADSPA 1.1 (along with 0dB=1.0f). Yes Steve, it has been
getting mythical, but I've actually been working through my list of
things-to-do for LADSPA (mostly website related) over the past week so there
is hope ;-)
> 2) LADSPA_IS_SYNTH
> 3) LADSPA_IS_PORT_GATE, LADSPA_IS_PORT_GAIN, LADSPA_IS_PORT_FREQUENCY
Not needed, see below.
> 4) LADSPA_IS_PORT_DYNAMIC
I don't understand this. Are we just saying this is an array? If so, I think
this goes beyond LADSPA's scope.
> 5) LADSPA_HINT_LOW_FREQ, LADSPA_HINT_HIGH_FREQ
I don't quite understand this, but hopefully this could be handled by clear
labelling for the user.
> 6) Optional string array for integer ports (e.g. waveform: sine, saw, ...)
Nice to have (MN has it), but out of scope IMHO.
> 7) Type of integer port int not float
Already present throught the hints (well, 24bits worth after casting).
> 8) Polyphony extension: arrays of type buf[poly][buflen] and control[poly]
> 9) LADSPA_IS_PORT_POLY
Not needed, see below.
> 10) Categories
Nice to have, but we didn't agree a way to categorise, probably out of
scope.
[...]
And now - my view of a simple way to build a LADSPA-only modular synth
(a.k.a. as P-Net, pronounced peanut). The components are all pretty trivial
I think you'd agree and require no changes to LADSPA. What they DO require
is three plugin IDs reserved for unusual use.
Components:
(1) An XML representation of plugin networks. These networks may represent
synth or processing networks (or "patches").
(2) An XML editor for the networks which can load plugins and represent
them nicely on screen. The XML representation may wish to use some kind of
coordinate system to make this look pretty. Big warnings should be presented
on screen when the user selects a plugin that is not tagged as realtime.
(3) Three special plugins that are provided by the *HOST* rather than being
loaded (a number of each of these may be present in the network). The
plugins are:
(a) [processing networks only] a mono audio input
(b) [processing networks or synth networks] mono audio output,
(c) [synth networks only] synth control input, with one control input port
and one control (or perhaps audio) output port. The input port selects which
synth control is required (1 for frequency, 2 for gate etc, 3 for velocity,
4 for modulation wheel or whatever).
(4) A synth program that accepts two XML plugin networks: one a synth, one
a processing network. The programs listens to a MIDI interface or file and
writes to an audio interface or file (and possibly a MIDI file). Multiple
instances of the synth network are used to play each note during polyphonic
use (the synth may reuse them for sanity) and the mixed results are passed
through the processing network.
As a sideline, the processing network representation one gets is rather
useful - it can also be loaded by a clever host as a plugin in its own right
or used as a self-contained realtime or offline signal processing
configuration.
More complex arrangements are possible (e.g. with multitibral behaviour,
matrix processing or sampler modules built into the host), but this gives
the basic idea.
... But I think most of this is available already through ecasound or
suchlike.
--Richard
This archive was generated by hypermail 2b28 : Tue May 14 2002 - 00:25:41 EEST