Subject: Re: [linux-audio-dev] A new audio plugin API ?
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Mon May 13 2002 - 17:49:28 EEST
On Mon, May 13, 2002 at 11:52:35 +0200, Dr. Matthias Nagorni wrote:
> Now the wishlist:
NB I regard these as proposals for a hypothetical new plugin format, with
a similar design to ladsap, other than adding defualts I dont think its
advidible/neccesary to extend LADSPA, it would be good to keep it as a
good format for beginner plugin writers.
> 1) Default values
yes :)
> 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
a bit semanticly weak, and too limiting.
> 6) Optional string array for integer ports (e.g. waveform: sine, saw, ...)
good idea, but not just for integer ports...
> 7) Type of integer port int not float
Don't think it helps much, in some cases there is a fine line between
integer and non-integer ports, eg. "mode" of diode_1185
> 8) Polyphony extension: arrays of type buf[poly][buflen] and control[poly]
> 9) LADSPA_IS_PORT_POLY
The host should be dealing with polyphony issues, otherwise the plugin has
to be reinitialised if the host wants to change the degree of polyphony.
> 10) Categories
Should be external IMNSHO.
> 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 is possiblt some argument for labeling CV ports, or at least an
agreed on a standard scale (late CV was 1v per octave, with 1v=440 Hz
IIRC, so maybe 1.0f per octave, 1.0f=440Hz is good).
> 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.
Its not neccesary to extend the plugin format to add this kind of
metadata, things like RDF are designed for exactly this and don't require
any addition to the data ittself, all it needs is a URI schema that points
into the ladspa domain of discourse, eg. ladspa:plugin#1181 or similar.
This would also allow greater expressivity in categorising plugins, they
could be grouped by arbitrary criteria, and new classes can be created
and expressed at any time.
- Steve
This archive was generated by hypermail 2b28 : Mon May 13 2002 - 17:45:00 EEST