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

Tim Hockin thockin at hockin.org
Sat Dec 7 03:31:01 UTC 2002


So, I'm incorporating the things that were discussed this week into my API
proposal.  It's starting to take shape, and I really appreciate the feedback
I got (why I can't get that level of feedback even at work, is beyond me).

I've hit a couple of large questions that I want to bounce off you all.

Per-voice controls vs. Master controls:
----
This is what I am thinking:  One of the flags on each control is whether it
is a CTRL_MASTER, or a CTRL_VOICE (or both).  This allows the plugin to
define a ctrl labelled (for example) VELOCITY and the host can connect it to
any MIDI input, if it wants.

Let's assume a plugin provides a control named FOO which is both VOICE and
MASTER.  Let's assume the current state of FOO is the value 50.0.  Let's
assume the sequencer triggers a voice and sets FOO for that voice to 80.0.
The user then turns the master FOO down to 0.  What happens to the value of
the voice's FOO.
	a) goes to 0
	b) ends up at 30.0
	c) stays at 80.0

Maybe controls that are both MASTER and VOICE should be absolute values for
MASTER and scalars against the MASTER value per-voice?

Needs discussion.

Triggering a voice
----
I see a few methods, each has pros and cons.

	1) * Host calls plug->note_on(timestamp, note, velocity), and 
	     gets a voice-id.
	   * Host sends n VOICE_PARAM events to set up any params it wants
	   * Host calls plug->run()
	   * Plugin activates the voice at the right timestamp with the
	     right params.
	   * Host calls plug->get_polyphony() to know how many voices are
	     playing.
	   * Host calls plug->voice_off(voice, velocity)
	
	2) * Host sends a VOICE_ON event with a negative voice-id and params 
	     velocity and note
	   * Host sends n VOICE_PARAM events for the negative voice-id
	   * Host calls plug->run()
	   * Plugin receives the VOICE_ON, allocates a voice-id, and and
	     sends a VOICE_ON event with the real voice-id and the negative
	     bogus one back to the host.
	   * Host sends a VOICE_OFF event to the plugin to end a voice,
	     plugin ACKs by sending it back.
	   * Plugin sends a VOICE_OFF event to the host if a voice is done
	     before the host sends VOICE_OFF (short sample, etc)
	   * Host keeps a count of voices, increment on VOICE_ON, decrement
	     on VOICE_OFF.

Modifications on those two:
	a) Same as #1 but with no voice_off() method - use VOICE_OFF events
	instead.

	b) Modification on #1 and #2 - don't pass velocity and pitch params,
	   instead have them as controls
	c) Same as b, except Velocity is not a continuous control - pass
	   velocity but keep pitch as a control (possibly pitch and
	   pitch-bend being different?  not sure).


Preset and state save/restore
----
Should each plugin provide serialize() and deserialize() methods (thus
storing plugin state from the plugin itself in an arbitrary string) or
should the host be expected to write-out each control's data?

I'm leaning towards serialize/deserialize.

So, I'm looking for ideas and discussion!

Tim



More information about the Linux-audio-dev mailing list