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
