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

Tim Hockin thockin at hockin.org
Sat Dec 7 16:19:00 UTC 2002


> Not defining them seperatly, but making a distinction, I dont think one
> control should be applied per voice and per instrument.

So one should not be able to manipulate a per-voice volume and a master
volume?

> > So no one has offered me any suggestions on how we handle the clash between
> > Master and per-voice controls.  To re-ask:
> 
> Ban it :)

I'm not sure we can reasonably do that.  We can say that no one control
applies to both master and voice, but then we end up always (or rather,
often) defining two volume controls, two pitch controls, two filter controls
etc and making them slightly different and behave differently in each plug.
Are we better to define the behavior, or at least offer a suggestion?

> No, velocity != loudless.

ok, we agree on that.

> However, even in midi there can be more than one velocity value per note,
> there is seperate release volcity IIRC. I expect the only reason attack
> velocity is package up with the note start in MIDI is because otherwise
> they couldn't guarantee it would arrive at the same time, and it saved a
> few bytes.

MIDI has 2 velocities - note_on and note_off.  I see velocity as specific to
those two events.  Isn't a new velocity event really a new strike or attack
of the instrument, or, in other words a new voice (even if it cancels the
previous voice)?  That said, I hate that Velocity is special.  I could be
convinced.  I could also stand and argue.  Not sure I know which I prefer...

> > we can say 'just load a new instance for the new channel'.  It prevents

> There are probably other reasons why you /might/ want this, but I cant
> think of anyoffhand. I suspect one is OK and it makes things nice and
> simple.

I agree, and simplicity is better, I think.  Still needs more noodling.  If
it is obvious and easy, then I don't really mind it.

> Analogue synths generally dont, some have channel pressure, but that is
> slightly different and variable through the duration.

channel pressure would be a separate control, just as it is in MIDI.

> Not really the host can just allocate them from a pool of 32bit ints (for
> example) and pass them in by the new_voice call.

but if a plugin controls another plugin (as suggested by David) the
'pseudo-master' needs to either be a full-fledged host, or needs to get a
pool of VVIDs from the host via a host->get_vvid() callback.  It's not TOO
bad, I guess..  But I don't see it as being a big-win on any front as
compared to a synchronous vid = plug->voice_on() mechanism.

> > This raises another question for me - the host sends events to the plugins.
> > Do the plugins send events back?  It seems useful.  The host has to handle
> > syncronization issues (one recv event-queue per thread, or it has to be
> > plugin -> host callback, or something), but that's OK.  Do timestamps matter
> > to the host, except as bookkeeping?
> 
> I'm not sure what the instrument will send back to the host that needs to
> be timestamped.

Me neither, but it is becoming morer apparent that a plugin DOES need to
send events back.  Arguments?

> Well, we were talking about floats, strings or opaque data blocks before,
> so presumanbly the event would be either a float, a pointer to a string or
> a pointer to a data block (+ a size).

Assuming that control changes are the only types of events that flow.

some events, off the top of my head..
VOICE_ON (plugin to host) ?
VOICE_OFF (plugin to host and host to plugin)
VOICE_CTRL (host to plugin)
MASTER_CTRL (host to plugin)
SILENT (plugin to host - sent when reverb tails or whatnot have died..)


> If you need to send it over a wire you will have to serialise the strings
> and blocks in variabley size chunks, but thats unavoiadable.

yes, and let's not make this a wire protocol :)  Seperate project.

> Its not purely aimed at instruments, but its heavily focused that way, it
> probably wouldn't make sense to use this API for something LADSPA can do
> well (eg. audio+control -> audio+control). If you need timestamps or
> polyphony then this would be the way to go, but realisticly that means
> intruments and a few other odd cases.

Well, assuming a LADSPA wrapper in this API, a host can transparently use
LADSPA plugins in a multi-channel way.  Stereo reverb can be built out of
two LADSPA mono reverbs.  Just an idea.



More information about the Linux-audio-dev mailing list