Subject: RE: [linux-audio-dev] LADSPA extension proposal (quick action wanted)
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Fri Dec 07 2001 - 02:00:02 EET
Oh dear, here we go again. Richard pops up to be a pain in the neck. The
suggestions:
CONTROL PORTS SHOULD ACCEPT ARRAYS
This is in the same family as a much more common request, "control ports
should accept strings" (or doubles, events, MIDI, WFT etc). This requires a
rather more complex API than LADSPA as the API has to handle memory
management and more complex port descriptors. This requires a lot more work
for the host programmer and is a potential barrier to plugin and host
programmer. More in "going beyond LADSPA" below...
GUIS AS PART OF THE PLUGIN
As I've said before, I'd prefer an approach where an appropriate delivery
mechanism can be chosen depending on the toolkit. Flat files may work for
XML, or perhaps calls into the library containing the plugin itself. For
instance, a host written in GTK might want to look for a
"get_LADSPA_gtk_GUI()" in the library containing the plugin. If it finds it,
fine. If not, the host might wish to look for an XML wrapper, Snd spec or
whatever else it supports. I think it's important that it is possible to
separate GUI and plugin (e.g. for remote control of a dedicated FX box).
I think work on a number of GUI standards of this type is useful, as long as
we can try to get a consensus within each toolkit framework. I'll put
archives/links on www.ladspa.org if that's helpful - I think the key to
getting this sort of thing to work will be to make everything visible - I
*still* don't have a copy of the XML GUI spec! Does anyone implement it yet?
CATEGORIES
Again, this is ancilliary to the plugin itself although it did nearly end up
in the original spec. Perhaps we should agree on a set of calls that the
library might support, possibly in a number of different flavours depending
on application requirements. I also like Steve's ontology idea.
XML FOR PLUGIN PARAMETER SETS
This is slightly OT but relevant - I think this is a good idea. To do it
"right" it needs to be compatible at least with any spec for networks as any
network standard will have to deal with plugin parameters sets. This will
probably happen anyway - is anyone looking at this? I have a fairly trivial
but powerful project called PNet that I keep meaning to find time for that
would use such files, so I'm very interested in this one (and could produce
the spec if necessary).
DEFAULT PARAMETER VALUES
I regret this didn't go into the original spec - sorry Steve! One for v1.1.
In the meantime, defaults can go into GUI specs (which to my intuition is a
reasonably natural home for them anyway).
PER-PLUGIN VERSIONING
Hmmm, not sure about this. PluginID+Version is just a bigger int, so we can
get away with just PluginIDs in principle. I'm not sure versioning helps
much - it's just two numbers rather than one in a XML network description or
suchlike. There are plenty of IDs out there still if folk need more. I'd
vote for use of a new plugin ID when an interface changes substantially -
otherwise old saved networks will break.
CHANGING CONTROL PARAMETERS DURING PROCESSING
Hmm, this does sound like my style of specification English (and the "[at]"
isn't appropriate IMHO!). I don't think it's unambiguous, although perhaps a
little convoluted - the plugin is guaranteed that it can take sin(*ctrl) at
the start of run() and cos(*ctrl) further on and get consistent results.
It's important for a number of the reasons that the user and plugin know
that the control value will stay fixed for the duration of the run() call.
Some that spring to mind: (A) What happens when LADSPA runs on future
hardware with small word sizes and larger floats? (B) Even if the float
access is atomic, what happens when the host changes two interrelated
control ports separately so inconsistent values are read by the plugin? (C)
What happens if the C/C++ optimiser thinks it's more efficient to read twice
from the control port? And it's pretty easy for the host to deal with the
problem on its side.
GOING BEYOND LADSPA
To quote part of the original posting (see
http://www.ladspa.org/original_api.txt), "I believe this plugin API should
be a subset rather than a superset of the logical functionality of systems
in use at the moment". I still think this is true. The idea was that almost
all plugins would work with almost all hosts with minimal effort. This has
worked - it's easy to add LADSPA support to hosts and the API is flexible
enough for most of the common DSP algorithms out there (and we were still
missing quite a few when I last looked, but then I haven't kept up with
Steve's excellent efforts!). Because of this and because new programmers
will carry on writing new hosts, I think we need to keep LAD*S*PA simple!
That's just the host side of things - IMHO the API is already of borderline
complexity for entry-level DSP plugin programmers.
However, Ardour needs a richer plugin API. MN has one. VST has one.
Quasimodo has one. aRts has one. GLAME has one. PD has one. Csound has one
etc etc. So how should the Ardour team deal with the issue? Writing yet
another incompatible API is obviously a bad idea. So I agree we need a
richer API, however I don't think this should be done through extensions to
LADSPA directly for reasons above. Instead, I'd like to see Ardour keep
compatibility with LADSPA but for us to develop a new, richer API for the
hard-core techies. It's probably be a good idea to base it on LADSPA to make
it easier for programmers (of both plugin and host) to graduate from one API
to the other. If it's done this way it could be called LADPA. I'm not 100%
sure this is the way to go - different designs (such as LADMEA, see
http://www.ladspa.org/ladmea/) may be appropriate once the horrors of memory
allocation, unknown data types, network transparency etc are faced.
I'll stop ranting now...
--Richard
This archive was generated by hypermail 2b28 : Fri Dec 07 2001 - 01:59:09 EET