Subject: [linux-audio-dev] Plugin madness
From: Guenter Geiger (geiger_AT_epy.co.at)
Date: pe loka 01 1999 - 04:22:56 EDT
As it seems it is getting calm around plugins again, everyone agrees
that they disagree ... and again an ambitious project for linux audio
died.
No !
Ok, letīs summarize. What do we actually need (or better what do
plugin writers need). We need to agree on a common level, which will
satisfy the needs for writing plugins.
Itīs really damn easy. No matter which audio engine, sound editor,
soft synth or whatever is built around. A plugin is not more
that a simple routine which modifies some signals, together with some
properties plugins share under each other, and parameters, or
k-rate signal or events or whatever you call them.
Parameters
==========
The point on which people seem to disagree are these "parameters".
Letīs look at it from the plugin programmers point of view.
He just wants to have some variable (letīs say of type "double"),
where he stores e.g his filter frequency.
The problem is, that this variable has to be communicated to the
application, so that the application can handle it, change it.
Ways to do it:
1) VST plugin like
The plugin programmer declares the variables he wants and communicates
them via some setparameter(), getparameter() calls.
--> not very efficient, as there is a function call for each parameter
change.
2) Quasimodo like
- the parameters are communicated as pointers, the application
can store them and acess the parameters directly.
--> better, more flexible.
3) Events system
<To be filled out by David>, I still donīt know how his will be handled.
Sample accuracy:
=================
1) Fixed buffer size, parameter are set with "sample offset" values.
The VST way
bad --> sample accuracy is only achievable by doing it in the process
function
2) Buffersize is passed as a process argument:
--> better of both worlds.
some applications want to have fixed buffers, and change paramters
directly between process() calls
other applications may implement an events system and call the process
function with different buffer sizes (up to single sample processing).
(NOTE: at this place I *can* imagine an events system, we may even
add an
Application Library
===================
where the whole events system is implemented, and probably other
solutions, multithreading and the like.
Ok, enough for now, I know we havnīt touched the GUI topic, but first
let us agree upon the Plugin API.
Letīs "Divide and Conquer"
Guenter
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST