Re: [linux-audio-dev] LADSPA Finalisation Deadline

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LADSPA Finalisation Deadline
From: David Olofson (david_AT_gardena.net)
Date: Sun Mar 26 2000 - 01:37:07 EET


On Sat, 25 Mar 2000, Richard W.E. Furse wrote:
> I'm proposing finalisation of LADSPA version 1. This would give a solid
> baseline for programming, possible further development and/or possible use
> within MuCoS.

Too much work left to say much, but I think the following would be
nice for MuCoS (which will probably *not* be a plugin API in itself,
but rather an extension to one), and for some other things:

---8<----------------------------------------------------------

typedef int LADSPA_PortDescriptor;

/* Property LADSPA_PORT_OUTPUT indicates what kind of port this is. */
#define LADSPA_PORT_KIND 0x000000ff

/* These are the official kinds of ports supported as of this
   version of the API: */
#define LADSPA_PORT_KIND_DISABLED 0x00 /* Port disabled */
#define LADSPA_PORT_KIND_AUDIO 0x01 /* Arrays of elements */
#define LADSPA_PORT_KIND_CONTROL 0x02 /* Single element */

/* Input ports of the kind LADSPA_PORT_KIND_EVENT hold a pointer to the
   first event in a linked list that the plugin is expected to parse. The
   list is terminated by a terminator event, which instructs the plugin
   to return to the host.
   
   For output ports, the port points at the last event in the list of events
   sent from the plugin. The plugin should add new events by attaching them
   at the end of this list. */
#define LADSPA_PORT_KIND_EVENT 0x03 /* Event queue */

/* Property LADSPA_PORT_OUTPUT indicates that the port is an output
   when 1, input when 0. */
#define LADSPA_PORT_OUTPUT 0x00000100

#define LADSPA_IS_PORT_INPUT(x) ((x) & LADSPA_PORT_INPUT)
#define LADSPA_IS_PORT_OUTPUT(x) (!((x) & LADSPA_PORT_INPUT))

#define LADSPA_IS_PORT_CONTROL(x) ((x) & LADSPA_PORT_CONTROL)
#define LADSPA_IS_PORT_AUDIO(x) ((x) & LADSPA_PORT_AUDIO)

---------------------------------------------------------->8---

The point is that I don't see why there should be multiple disallowed
combinations, as well as scanning bits one by one in order to find
out what kind of port this is. A single port can only be of one kind
at a time, right? Likewise for input/output...

(The LADSPA_PORT_KIND_EVENT stuff is preliminary, and doesn't change
anything for plugins/hosts not using it, so it probably shouldn't go
into the API yet.)

> If there are no significant *new* issues arising this week then I'll
> finalise the version 1 next weekend (2nd April 2000). We still need an
> introductory text on the API but I can produce this if push comes to shove
> and there's no deadline for the external docs anyway. Do people think the
> header file is adequately explicit to avoid confusion later?
>
> The only still-open question in my mind is whether or not to include a
> runAdding() method. This would require the addition of functions of the
> following form: runAdding(handle, samples) and setGain(handle, output port
> [NB!], gain).

Ok; the last one actually makes this useful. (I saw some posts on the
VST list indicating that existing VST hosts actually don't use the
adding method... If that's true, I can see why.)

> runAdding() is assumed to have implications for all output
> ports, audio or control. I think this is horrid and won't include it unless

Might be hard to avoid without the performance win being lost to
overhead in the plugin.

OTOH, in Virtual Studio enviroments (that's what VST was designed
for...) most plugins don't have all that many outputs, and usually,
the (1 or 2) outputs are connected to a bus, together with lots of
other plugins. With the setGain() functionality, this can actually be
done.

As for actual performance figures for authentic setups, I can't help
you though... This has to be tested thoroughly, as I'm afraid the
experiences from VST is irrelevant here, due to the lack of gain
controls in that system.

//David

.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Mar 26 2000 - 02:24:57 EET