Subject: Re: [linux-audio-dev] Real time plug ins
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Tue Mar 14 2000 - 18:20:32 EST
>It is not the loading of the plug-in "class" that must be real time, but the
>instantiation of an instance of that class.
But from the API, there is no way to determine what on earth an
"instance" means. The API as written does not make it completely
unambiguous when a host would call the instantiate callback, but my
interpretation is that it would always be done right after loading.
I.e. what you mean by "instantiation" is different that what the
"instantiate" routine does.
>SC never statically allocates voices or unit generators before hand since
>there is no way to know ahead of time what will happen in a completely
>dynamic environment. Everything is instantiated in response to events in
>real time. There is no reuse of voices. SC garbage collects expired objects.
LADSPA, like VST1.0, has no such thing as "events". So the behaviour
you are describing is impossible in a LADSPA host. The best you could
do would be block-accurate event handling, based on the value accessed
via a control port. MuCoS is the only V-API (vaporware API :) that
we've discussed here that supports events.
What you are describing are a set of limitations that, to the best of
my knowledge, plugin APIs like VST & TDM do not require. TDM has its
drawbacks, but if its good enough for a majority of digital pro
studios, I figure its probably good enough. The code in a TDM, or for
that matter, a VST, plugin, must clearly not violate the real-time
bounds of the host's audio-time execution. If the host makes it clear
that it instantiates during execution as you describe SC doing, then
that clearly limits what instantiation can involve.
But LADSPA, VST and to my knowledge, TDM, do not instantiate an
instance of a plugin class within the audio-time execution of the
host. Instances are created in a distinct time frame (and/or thread),
then placed in the execution flow graph, and allowed to run. If they
want to take some specific action when an event happens (if the API
supports such things), then that happens during their run()/process()
call, and it must clearly be bounded by real time constraints. That
action could be anything, including things that you may consider to be
"the instantiation of a ugen", but I don't think that any of these
API's envisages instantiating an instance of the plugin class in the
general sense.
Of course, if the plugin is utterly trivial (e.g. a pure ugen; DSP
function; opcode; whatever), then real-time instantiation is almost a
no-op anyway. But LADSPA and the rest are API's for generalized
plugins, not just low level elements that can be guaranteed to meet RT
constraints during instantiation.
At least, thats my reading of it/them.
>Sorry I came in the middle of all this. I'm just trying to determine what
>the parameters are.
Your input is welcome, and valued. Sorry if my tone sounds too pushy,
its just me. I'm working on it :)
--p
This archive was generated by hypermail 2b28 : Wed Mar 15 2000 - 01:47:54 EST