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

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

Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Tue Dec 03 2002 - 13:54:50 EET


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


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

This archive was generated by hypermail 2b28 : Tue Dec 03 2002 - 14:03:28 EET