Subject: Re: [linux-audio-dev] Plugin madness
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe loka 01 1999 - 16:22:56 EDT
Thanks to Geiger to attempting to summarize the voluminous discussions
on plugin API's in the last couple of weeks. I don't want to take the
spotlight away from the summary view, but I do need to clarify a
couple of things.
>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.
actually, Quasimodo is closer to (1) than to (2). A GUI or any other
part of a system that communicates with the Quasimodo engine uses
Parameter::set() in order to reset the value. That function in turn
calls another function, Plugin::parameter_edit() (well, its actually
Module::plugin(), but I'm trying to keep with the terminology :) which
carries out the *many* steps (many compared to "*p = newval;")
necessary to change the parameter.
[ why is a parameter not a pointer ? 2 reasons. parameters exist,
for the most part, as part of the closure that is passed to the
plugin code as its argument. plugins are not "instantiated"
until necessary, and neither are their closures. this means there
cannot be a pointer to the parameter, since the memory location
where it will live doesn't exist until the plugin is instantiated.
Why not create one and bind it to the plugin ? Well, we do, in
the sense that instantiated plugins (called DspProcess-es) are
kept around and reused. But that doesn't help us because of the
second reason. Some plugins can be used polyphonically - that
is, we instantiate multiple copies of them in response, say, to
MIDI NoteOn messages. Each one is running with different values
(say, for pitch) stored in its closure. So, editing a parameter
for such a plugin actually means altering the data stored at
*several* locations.
]
However, its not a system like David's proposed event system, in that
no synchronization or communication is carried out between the GUI (or
automation system) and the DSP engine - the value of the parameter as
seen by dereferencing a pointer within the plugin's code can change at
any time without the plugin code or the engine "knowing" it. In this
sense, it is highly efficient. It cannot, however, support sample
accuracy.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST