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

David Olofson david at olofson.net
Sat Dec 7 18:35:01 UTC 2002


On Saturday 07 December 2002 22.13, Tim Hockin wrote:
[...]
> > > 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?

2D "address space":
	Dimension 1:	Channel
	Dimension 2:	Control

One channel would be reserved for Master Events, and the others would 
(obviously) deal with Channel Events. For each Channel, you can ask 
for a list of Controls, and these should be named and hinted 
appropriately.


[..]
> 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)?

Nope. An a violin, you have no "velocity" event at all (unless you 
want to use it for the subtle sound of the bow impacting or leaving 
the strings), but rather a "bow speed" event - which is continous.


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

Well, keep arguing, and I'll try to figure out more reasons why 
velocity is not special, nor universal. ;-)


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

If you want to keep your plugin simple, just say you support min 1 
and max 1 channels, and that's it - you can hack away just as if the 
API supported only one channel.

As to the host, a multichannel plugin would correspond to an array of 
single channel plugins with *one* exception: In the case of single 
channel plugins, you'd have to copy all Master Events to each 
instance, while in the multichannel case, you just send them to that 
single Master Event port.


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

What if you need *only* pressure, and don't care about attack or 
release velocity? Why not just make velocity optional as well? :-)


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

I think the plugin should just ask the host for the number of VVIDs 
it wants for each event output port, and let the host deal with it, 
since the host knows where those outputs are connected.


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

(See previous posts.)


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

A plugin can't really send events *back*, as it can't know more than 
which port the events arrived on, unless there is a "sender" field in 
all or some events. I think that in most cases, events that need 
replies will come from the host - so you can just send the replies to 
a "fixed" host event port. Either way, this stuff probably won't need 
timestamps, because it won't even happen when the plugin is in the 
processing net.

However, it might be handy for the host to be able to ask for the 
values of specific controllers. It may or may not be useful to do 
that multiple times per buffer - but if it is, you'll definitely want 
the timestamps of the "reply events" to match those of your request 
events, or things will get hairy...

Either way, this is really easy: Whenever you reply to an event, just 
copy the timestamp field from the request event.


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

Sounds ok.


> SILENT (plugin to host - sent when reverb tails or whatnot have
> died..)

Great idea. Sample accurate end-of-tail notification. :-) (In 
Audiality, I do that by fiddling with the plugin state, which is 
rather ugly and not sample accurate.)


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

Let's not *prevent* it from ever being a wire protocol, unless 
strictly nescessary. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list