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: Tim Hockin (thockin_AT_hockin.org)
Date: Wed Dec 04 2002 - 19:19:50 EET


> 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?


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

This archive was generated by hypermail 2b28 : Wed Dec 04 2002 - 19:30:43 EET