Subject: [linux-audio-dev] Levels, Instantiate, Extensions/Finalisation
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Wed Mar 15 2000 - 22:04:18 EST
Hmmm. My two cents worth on 'levels' for plugins, 'instantiate' issues,
possible further extensions and finalising LADSPA.
LEVELS
I'm very eager that the 'level' discussion should not become an issue for
LADSPA. To me, a the LADSPA plugin interface is (was?) the simplest way to
achieve the following framework:
(A) Audio is passed in buffers of numbers. A data item is a number.
(B) The plugin will read some audio and/or data items from somewhere and
will write some other audio and/or data items to somewhere.
That's really it. The rest of the API deals with the faff of accessing the
code, letting the host set the above up in the simplest way possible,
simple instance management and self description. The idea is that
simplicity breeds compatibility...
As far as I can see, the description above and thus (hopefully!) LADSPA
just says 'something that processes audio' and I'm not sure that levels
really come into it - unless perhaps we consider the level of descriptive
information provided. The self description part has become vastly extended
but the heart of the API remains the same.
Perhaps the self description part has been extended too much - the header
file is now 90% bigger and IMHO much less easy to take in at a glance. This
risks the plugin/host coder getting the impression that the API has a
larger overhead and might be inflexible. Any thoughts people?
INSTANTIATE
The intention when the API was written was that the instantiate() call
would be used by the plugin to allocate and initialise a data structure
describing the state of a plugin instance. In OO terms, the instantiate()
is the plugin constructor, cleanup() the destructor. If you want to use
four compressors at the same time you call instantiate() four times. I'm
wondering if I'm missing something?
Perhaps we should make the comments around the instantiate() declaration
clearer. The only other source of confusion I can think of are the
'ImplentationData' field and 'Descriptor' parameter to instantiate(). These
can usually be ignored when reading the API as an overview but are a useful
hook for plugin libraries using macro languages (e.g. aRts).
As far as I can see SC should be fine instantiating appropriate plugins at
runtime but IMHO instant initialisation is not practical in general and
should not be mandatory. My vote, as I think I posted before, is that SC do
timing tests, perhaps offline in a separate program, to establish what
plugins instantiate are fast enough for use live.
FURTHER EXTENSIONS and FINALISING LADSPA
I suppose I'm trying to make myself act as a 'low pass filter' on the
thoughts on this list - picking out the ideas that stand up well in
sustained discussion and checking they don't break things for people who
are basically happy already. Current main threads of interest:
(1) I can see the arguments in favour of some kind of initialise()/finish()
functions on plugins. They are hooks that can be mostly ignored by the
plugin developer and are rather useful at times. They are a little hassle
for the host but not much if the host just calls them along with
initialise() and cleanup() - and they do have some interesting implications
for device access etc on more careful hosts.
(2) Yes yes yes I've not been completely ignoring you all ;) An optional
runAdd() method could be useful too as a specialised performance
optimisation. Plugin writers don't include these if they don't want to and
hosts can ignore them.
My only real objection is that these add flab (size, complexity, potential
confusion) to the API. I be convinced on both counts if enough people are
interested. Sounds like you probably are on runAdd() - I hope you're not
just copying VST though... (Finally had a chance to look at the SDK last
weekend.)
Is it only me who wants to keep this API simple? I'd like actually to nail
it down as soon as possible so it can be nice, short and simple - and so
people can take the plunge actually to code serious plugins. Otherwise
we'll end up with another vapourware situation. I assure you the system
works as is - the example hosts and plugins work fine and MN has a quite
happy little plugin wrapper that only took a couple of hours to code up.
-- Richard
-----Original Message-----
From: Paul Barton-Davis [SMTP:pbd_AT_Op.Net]
Sent: Wednesday, March 15, 2000 12:45 PM
To: linux-audio-dev_AT_ginette.musique.umontreal.ca
Subject: [linux-audio-dev] more on plugins/LADSPA
[ this may be a repost of some stuff that james resent here as well,
but i haven't seen his repost yet, and thought it important. ]
james and i continued our discussion offlist, not entirely
intentionally. the eventual outcome was the recognition that:
>James writes:
>>
>> Paul writes:
>>
>> There seems to be a great deal of confusion over what the term
>> "plugin" means. At one time, I thought it Ok for it cover both these
>> low-level things ("opcodes", "ugens", "DSP functions") and the high
>> level things ("Sci-Fi", "AutoTune", "Cycling '74", "DeSpider" to name
>> some examples of plugins that spring to mind).
>
>OK I see. There are probably several levels of plug ins then, and so what
I
>was asking for is not appropriate at this level.
>
>1) Something like BeOS MediaNodes. Very heavy weight, more like full apps
>that can be piped together.
>2) Statically allocated large processes/effects with GUIs, automation. VST
>and TDM plugins fall here.
>3) Lightweight unit generators. MSP, Csound, SC unit generators.
I think that this is *VERY, VERY* important. We need to make sure that
we define the level(s) that LADSPA is intended to cover. Then we need
to make sure that it the API is adequate and sufficiently well
specified to do so.
One specific example (the one that we were discussing): the meaning of
"instantiating" a plugin has very different connotations and
implications depending on what type of plugin it is (see above
examples).
--p
This archive was generated by hypermail 2b28 : Thu Mar 16 2000 - 05:37:42 EST