[linux-audio-dev] Plugin APIs (again)

Steve Harris S.W.Harris at ecs.soton.ac.uk
Tue Dec 3 07:00:01 UTC 2002


Fisrt off, I agree with Conrad, its better to make this fucused on, and
really good at, one task (ie. instruments), that be OK at lots of things.

On Mon, Dec 02, 2002 at 04:03:18 -0800, Tim Hockin wrote:
> /* forward declarations of the fundamental OAPI types */
> typedef struct OAPI_descriptor		OAPI_descriptor;
> typedef struct OAPI_control		OAPI_control;
> typedef struct OAPI_ctrl_int		OAPI_ctrl_int;
> typedef struct OAPI_ctrl_float		OAPI_ctrl_float;
> typedef struct OAPI_ctrl_enum		OAPI_ctrl_enum;

Enum's good, I'm not so sure about int or string, a well defined enum type
probably makes string unneccesary and int is probably not needed.

> /* Plugin types: all OAPI plugins are one or more of these. */
> #define OAPI_TYPE_SOURCE		0x01
> #define OAPI_TYPE_EFFECT		0x02
> #define OAPI_TYPE_SINK			0x04

I dont think this helps, it should be obvious by inspection whether an
instrument is appropraite for the situation the host wants to fill.

> 	/*
> 	 * These are display-friendly fields, which hosts can display to
> 	 * users.
> 	 */
> 	const char *oapi_version;
> 	const char *oapi_author;
> 	const char *oapi_copyright;
> 	const char *oapi_license;
> 	const char *oapi_url;
> 	const char *oapi_notes;

If you're going to support metadata, support the Dublin Core, but generally
extrnal metadata is better than internal. Just provide a unique ID and
metadata can refer to that.
 
> 	int oapi_inputs_min;
> 	int oapi_inputs_max;
> 	int oapi_outputs_min;
> 	int oapi_outputs_max;

Variable numbers of i/o is interesting, but I'm not sure if it
overcomplicates things from the instruments point of view. Can you explain
why you think this is a good idea?
 
> 	int oapi_channels_min;
> 	int oapi_channels_max;

I'm pretty confident this is not the right way to go. If it matters to you
what output belongs to what channel then well known labels would be
better, I think.
 
> 	/*
> 	 * create: instantiate the plugin

Maybe better to stiuck to LADSPA nomenclature? It might not be perfect,
but it would avoid confusion.

> 	/*
> 	 * set_rate: set the sample rate

LADSPA definatly got this right, make it an argument to instantiate.
Changing the sample rate of system is not an RT operation, so theres no
need to make it ultra efficient, and instruments will have a very hard
time rejigging everything. Simpler to just remove and instatiate a new one
with the same settings.

> #if 1 //two options for note-control
> 	/*
> 	 * voice_on: trigger a note
> 	 */
> 	int (*oapi_voice_on)(void *plugin, int note);
> 
> 	/*
> 	 * manipulate a playing voice
> 	 */
> 	int (*oapi_note_off)(void *plugin, int voice);

I prefer this one.

After reading this I think the best solution is something very like LADSPA
but with note_on and note_off calls. Other useful things like enum types
/can/ be added via external metadata, eg RDF ;)

- Steve



More information about the Linux-audio-dev mailing list