Version 1.0 written by Steve Harris <steve AT plugin.org.uk>, 2003-10-01
LADSPA is a simple plugin system devleoped for realtime Linux audio applications.
LADSPA has been ported to most platforms supported by Linux, including X86, Power PC, MIPS and some Palmtop platforms, plus it has been ported to Free BSD, Mac OS X and a Windows port has started.
I have no direct experience of the ports so I cant say how easy it was.
Portability does not appear to be an issue.
LADSPA only provides audio and (continuous) control data processing. It cannot handle events.
This causes few problems for general audio processing (provided the block size is sufficiently small), but rules out softsynths.
Desktop/server class machines, and high end palmtops.
I've no experience of running LADSPA plugins on palmtops - I would expect you would require hardware float support to make it practical.
Same.
Anyone.
General audio plugins and Modular synth modules. Chorus, Flange, Reverb, etc. But no softsynths.
I have not found any problems implemnting non-synth "plugins" under LADSPA.
Audio in and/or out, Control in and/or out.
3.1 - 3.2 are already answered above.
LADSPA is natively C, but wrappers for other languages can, and have, been written.
Basing the spec in C seems to have been a good choice for portability reasons.
LADSPA's API is defined by one, fairly short .h file - there is no standard LADSPA support library.
LADSPA provides no inherent threading support.
Plugins can elect to be "relate safe", if they do they have to meet certain real-time constraint in their run() (processing) callback.
No.
None.
This would be useful for e.g. tempo synced delays.
All audio streams are mono, un-interleaved.
This has not proved to be an issue, but there are few surround capable LADSPA plugins.
All audio streams are of type LADSPA_Data. In principle this is platform/version dependent, but in practise it has always been IEEE float up to now.
I suspect moving to a non flaoting point type would require extensive porting work. Moving to other bit-depths of floating point should be less difficult.
All audio streams are PCM.
This has not proved to be a problem.
I/O is handled with pointers to vales or buffers. Buffers are allocated by the host.
This has not proved to be a problem.
Plugins are expected to allow in-place processing by default, but may flag that they do not support it.
This has not proved to be a problem.
There is no automatic silence handling.
This has not proved to be a problem.
Parameters (control ports) in LADSPA are single, un-timestamped LADSPA_Data (see §7.1.2) values (constant for the duration of one block) or one-value-per-sample streams (audio rate).
Generally this is not a problem, but there are occasions where sample accurate parameter events would be more efficient.
Parameters are ungrouped.
I suspect that OSC style parameter grouping (eg. /lfo1/rate, /lfo1/wave) would be useful, especially for automated GUI creation.
Handled by the host. There is a more-or-less defacto standard XML document for storing the values.
Only LADSPA_Data, though hints may be put on this type, specifying that it is integer valued, log scaled and so on.
This seems to work well in practise, but Strings would be useful for file i/o and enumerations would be useful for better automated UIs.
LADSPA has no persistence features.
This would be useful for e.g.. saving the contents of delay buffers.
LADSPA has no intrinsic thread support.
There are times (e.g. asynchronous FFT processing) where it would be useful.
LADSPA has no intrinsic GUI support. Currently most GUIs are built automatically by the host - some hosts generate UIs using per-plugin XML descriptions of a GUI.
Prototypes have been built that invoke external processes to control the plugin - passing parameter changes with sockets via. the host.
Arbitrary, custom UIs are a significant omission from LADSPA.
MIDI is handled by the host and converted to LADSPA parameter changes.
Generally this works well for host created UIs, but would be tricky to choreograph when dealing with custom UIs. LADSPA has no standard way of handling MIDI Note On messages and co.
LADSPA plugins consist of a .so (shared object) file containing some basic metadata (names, labels authors) and the executable code. Each .so file can contain an effectively unlimited number of plugins. Optionally (not part of the spec) an RDF metadata description file classifying the plugin(s) and providing further metadata may be provided.
Plugin directories can be located through the LADSPA_PATH environment variable.
Each .so file must be loaded and interrogated to determine whether the plugin(s) are applicable to the host and to discover metadata.
This can take a noticable ammount of processing time if you have a lot of plugins installed, but doesn't appear to be a serious problem.
LADSPA provides no explicit support for copy protection.
LADSPA provides no explicit support for I18n or L11n, but gettext can, and has, been used to provide I18n.
This works well.
LADSPA plugins can't have thier sample rate changed without reinstantiating them. All other parameters can be changed and any time between calls to run(). Sample rate is provided to the plugin at instantiation time.
There are no other instantiaton time parameters.
This works well as sample rate changes are relativly rare and can have quite a dramatic effect on plugin internal data. The lack of other instantation time parameters (eg. max. delay time) is not a serious issue.
LADSPA plugins are source compatible across multiple platforms, but the host implementation varies depending on the platform.