Subject: [linux-audio-dev] A new audio plugin API ?
From: Dr. Matthias Nagorni (mana_AT_suse.de)
Date: Mon May 13 2002 - 12:52:35 EEST
Hi,
The importance of a widely-accepted audio plugin interface is reflected in
the fact that the subject of LADSPA extension is quite frequently
discussed on this list. After having implemented two hosts for LADSPA, I
would like to present my wishlist for LADSPA extension (or better a new audio
plugin API) in this email. Most of this has already been discussed previously
on this list. I hope that it is now possible to actually establish a new widely
accepted audio plugin interface. I have no experience yet in creating an
API, but once a new set of features is agreed upon, I can try to implement
them with the help of either people on this list and/or colleagues at SuSE.
Once the plugin API is implemented I would like to write a HowTo with code
examples and a QT plugin GUI library. Hopefully Steve can provide some
plugins ;-)
My perspective is that of a modular softsynth developer. This might seem to
be a bit specific. In my opinion however, regarding flexibility and features,
modular softsynths present the most demanding applications for audio plugins.
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
modules could not only share their modules but, even more important, presets
could be used on any modular softsynth implementing a host to the new plugin
API. I don't think it is necessary to provide GUI functionality to the API,
so leaving it pure C without GUI seems fine to me. The already existing port
hints and the modifications listed below will provide enough information to
allow easy GUI creation by the host. Perhaps one could write a separate GUI
library for creating plugin GUIs.
Now the wishlist:
1) Default values
2) LADSPA_IS_SYNTH
3) LADSPA_IS_PORT_GATE, LADSPA_IS_PORT_GAIN, LADSPA_IS_PORT_FREQUENCY
4) LADSPA_IS_PORT_DYNAMIC
5) LADSPA_HINT_LOW_FREQ, LADSPA_HINT_HIGH_FREQ
6) Optional string array for integer ports (e.g. waveform: sine, saw, ...)
7) Type of integer port int not float
8) Polyphony extension: arrays of type buf[poly][buflen] and control[poly]
9) LADSPA_IS_PORT_POLY
10) Categories
Detecting a synthesis plugin can be done either by scanning for
audio input ports and setting isSynth = audioInPorts == 0
or by defining a new hint LADSPA_IS_SYNTH ==> 2). A synthesis plugin usually
has to be connected to the MIDI event handler of the host. So the host needs
to know the gate, gain envelope and frequency ports of the plugin ==> 3)
The host acts like a MIDI to CV converter and applies the "control voltage"
to the frequency port. Velocity and envelope control is done on the gain
port. NoteOn events set gate to 1, NoteOff events set gate to 0. This way
the plugin can init some variables, e.g. the phase of an oscillation, when
receiving a NoteOn event. Gain and frequency ports should be arrays to allow
e.g. LFO input.
There might also be other parameters which need dynamic control ==> 4).
LADSPA_IS_PORT_DYNAMIC should imply that this port takes an array similar to
an audio port. For dynamic ports it might be useful to give a hint, whether
the frequency applied to the port is assumed to be in the audio or subaudio
range ==> 5).
The values of integer ports often have a special meaning. Therefore it
should be possible to supply a name for each of the values ==> 6). This way
the host GUI can build a combobox style selector. It would also be nice, if
the type of integer ports would be int instead of LADSPA_Data = float ==> 7).
Implementing polyphony with LADSPA synthesis plugins is only possible by
creating several instances of the same plugin. It might be more efficient to
allow ports to accept polyphonic arrays ==> 8). In this case, ports should
tell whether they expect polyphonic data ==> 9). A VCO plugin e.g. would
have polyphonic gate, gain envelope, and frequency ports. Other ports, like
e.g. waveform selector, pitch offset, etc. would accept single values.
The issue of categories for plugins has been discussed previously. Of course
it would be helpful to the user if the host could group the plugins by
category ==> 10). This could be done simply by adding a string "category"
to the LADSPA descriptor struct. A host could then scan all plugins for this
string field and create a new submenu for each category. Right now,
AlsaModularSynth creates a submenu for each .so object while the menu items
in the submenus are provided by the plugin names.
Thank you for reading this lengthy email ;-)
Comments, suggestions ?
Matthias
-- Dr. Matthias Nagorni SuSE GmbH Deutschherrnstr. 15-19 phone: +49 911 74053375 D - 90429 Nuernberg fax : +49 911 74053483
This archive was generated by hypermail 2b28 : Mon May 13 2002 - 12:45:54 EEST