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

Tim Hockin thockin at hockin.org
Wed Dec 4 12:25:01 UTC 2002


> In modular synth systems there are good reasons why you want to know
> whether things are connected (and good reasons why they wouldn't be), but
> this spec so far is not useful to a modular synth, so in this case I
> agree.

Can you expound, if only for curiosity?  Both reasons why it's useful for
modular synths and why this API is not?

> Interleaved data is more trouble that its worth IMNSHO. I think

I agree with that.

> multichannel outputs are extra complexity with no benefit.

I'm coming round

> I'm not sure what peoples opinions on numbers of outputs are, obviously the
> number needs to be variable per instrument at development time, but I dont
> think it should be variable at instantiation time, that doesn't sound
> useful, and it would be hell to optimise.

I'd agree with this, but for a few exceptions:
* Mixer plugin.  I really do want it to have a variable number of inputs.  I
don't want to say 48-channels or 128-channels.

> It seems like you need two sets, per instrument and per voice, they should
> share the same interface, and the per voice ones definatly should not be
> limited to modulation,chorus,whatever.

what if each control has an int per_voice; field.  If the field is 0, that
param is not modulatable per-voice.  If it is > 0, it is an instrument-unique
ID which can be used by the host to modify that param: 
	plug->voice_change(plug, voice_id, param_id, value);
(or whatever it will look like if we go the way of all events).

Can we assume that all voices have a standard control mapped to velocity?  Or 
should the per-voice controls actually be another set of controls, and each
instrument needs to specify velocity,pitchbend (and others)?

As a similar: should instrument plugins be providing hints as to their
MIDI-equivalent functionality?  CC-equivalent numbers per control, perhaps?

> My feeling is that just float+"arbitrary opaque binary data" is enough.
> The float can be augmented with hints, enumerations, whatever.

String is needed if we want to deal with filenames without a custom GUI.
Opaque binary data has no meaning to the host, and the host is what
manipulates controls.  Where does it get that data?



More information about the Linux-audio-dev mailing list