Subject: Re: [linux-audio-dev] A new audio plugin API ?
From: Dr. Matthias Nagorni (mana_AT_suse.de)
Date: Mon May 13 2002 - 20:32:38 EEST
On Mon, 13 May 2002, Steve Harris wrote:
> > 6) Optional string array for integer ports (e.g. waveform: sine, saw, ...)
> good idea, but not just for integer ports...
For which ports else ? Toggles ?
> > 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
It makes the code for the GUI routines simpler. If integer port variables
are int, their pointer can be directly passed to the integer GUI element.
> > 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.
Well, not necessarily. You could add inc_poly and dec_poly routines to the
interface. OK, but polyphony integration is not so important. So perhaps
let's first agree upon the other features. Then we can see how much
overhead the current approach of just handling multiple instances of the
same plugin would mean for the host.
> > 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 idea of directly using the old Moog-style CV has the advantage of not
limiting the max frequency, so I like this idea. However, it will make
these ports logarithmic. What about the other ports ? Gate and Gain ?
Some people might also want aftertouch.
> 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.
OK, but don't forget that the data must be such that a host has a way to
automatically create menus. The string categories I suggested could be
directory-like, e.g. synth/organ
synth/noise
filter/lowpass
If you later decide to refine this you can define
synth/organ/pipe
synth/organ/jazz
filter/lowpass/2pole
filter/lowpass/4pole
The host can then decide how many menu-levels it would like to create,
maybe dependend on the number of plugins actually available in the
categories.
What about the frequently discussed arrays ? I have seen from your code
that you just use audio ports whenever you need arrays. I would prefer to
distinguish between audio and control ports.
More tomorrow...
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 - 20:48:39 EEST