Subject: Re: [linux-audio-dev] LADSPA extension proposal (quick action wanted)
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Dec 07 2001 - 03:59:26 EET
>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).
the proposal right now is to short circuit all that stuff and allow
people to write GUIs that are completely disconnected/unconnected from
the plugin. that is, the plugin doesn't know about the GUI in any way.
the XML spec was a good idea, but (1) it has not been implemented and
(2) doesn't offer developers (read as "steve") the chance to really
"design" a GUI the way that something like libvstgui does. rather than
implement libvstgui (which i still may do), the proposal at hand will
allow people to write GUI's using any toolkit, and to have those GUIs
be useful with any host, regardless of the hosts toolkit (or lack of
one). in essence, its a "hands off" approach enabling a diverse
approach to GUIs that will maximise individual programmers'
preferences and skills with different toolkits. note: this proposal
relies somewhat on the following (evolving) API for those GUI
processes:
----------------------------------------------------------------------
typedef struct __ladspa_control_protocol_client lcp_client_t;
lcp_client_t *lcp_open (pid_t pid);
int lcp_close (lcp_client_t *client);
int lcp_write (lcp_client_t *client,
unsigned long plugin,
unsigned long port,
LADSPA_Data value);
int lcp_read (lcp_client_t *client,
unsigned long plugin,
unsigned long port,
LADSPA_Data *value);
----------------------------------------------------------------------
this provides a standardized way for the GUI's to move information
back and forth with the host, and eliminates GUI authors from having
to think about how to do this.
the main area of potential evolution right now concerns the right form
for the argument to lcp_open(). if the GUI's are always on the same
system, which they would be if fork/execed by the host, `pid' makes
sense. but for more generality, GUI's could be started on other
systems (PDA's anyone?) and then sockaddr_in or something similar
would be appropriate.
>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.
in quasimodo, i followed taybin's suggestion of not dictating anything
about the categories a "module" (read: plugin) could claim to belong
to. as long as people are reasonably sensible, and pay attention to
"common practice", this will accomplish the goal richard g. set out.
steve's ontology idea seems like overkill to me, nice as it is.
>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).
its true that they can go there. but its not *the* natural home for
them, since some hosts may choose not to instantiate any GUI. do you
agree with the proposal that steve&i offered for specifying these values?
are you amenable to a release of v1.1? this has been one of the
biggest problems with using steve's plugins: the absence of default
values means that they often come up with silly settings (no sound,
incredible screeching, etc.)
>CHANGING CONTROL PARAMETERS DURING PROCESSING
>
>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.
actually, its not. it means adding an entire extra step to the host's
main loop, plus another queue (preferably lock free) of parameters to
be changed plus the new values.
>GOING BEYOND LADSPA
>
>However, Ardour needs a richer plugin API. MN has one. VST has one.
actually, we don't need one at all. LADSPA is just fine from Ardour's
perspective. The problem here is that plugin *authors* want a richer
plugin API to do their work justice. i think steve is just running
into a brick wall of being unable/finding it very hard to create
LADSPA plugins that go beyond a certain level of functionality because
the GUI's that get built for them are impoverished and there is no way
to handle array data (or strings). things like companders, parametric
EQ and so forth are really, really hard to do properly in LADSPA, not
because the DSP code can't be written but because there is no decent
way to control their operation.
>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
the question has been raised why we don't just do VST ... still, we
faced that one at the same time as LADSPA was developed, and in most
sense LADSPA is still a subset of VST.
--p
This archive was generated by hypermail 2b28 : Fri Dec 07 2001 - 03:58:31 EET