Subject: Re: [linux-audio-dev] GUI<->Plugins
From: David Olofson (david_AT_gardena.net)
Date: la maalis 11 2000 - 16:03:03 EST
On Fri, 10 Mar 2000, Alexander Ehlert wrote:
> Hi,
>
> I just had another wierd idea that could actually be a problem :)
> Just imagine a plugin that want's to have a LUT as one parameter, e.g.
> a waveshaper, generic filter... That seems to be no problem with ladspa,
> parameter ports just take a pointer to whatever float/array of floats?
> But for defining a LUT in a GUI you surely want to have a widget in your
> host application using splines, freedrawing, blabla...
> A plugin like that may be easy on the LADSPA layer, but you can't just
> write a plugin like that without a GUI in mind. And that's highly
> dependend on the actual host application. One way would be to define a set
> of commonly used control datatypes in ladspa that allow hosts to construct
> reasonable GUI's, another way that someone already mentioned is to write
> an own GUI for your filter. But even then you would need a sane way for
> GUI to communicate with its plugin through the host. There's no way
> running the gui from within the plugin thread.
> Any thoughts ?
In MuCoS, I'll solve this with "custom events", which are similar to
the audio streaming system ("huge block events"; events with
data pointer + size fields).
Of course, any plugin that doesn't come with a custom GUI plugin has
to use some data format for which there are standard GUI elements
available.
There are basically two extreme approaches;
1) No complex data types supported by any host.
Plugins *have* to provide their own GUI plugins unless
they use only the data formats covered by the API spec,
(ie the ones that there should be support for in the
standard converter plugin array) and normal controls.
2) Only data types defined in the API spec can be used.
A host or system has to support a certain set of data
types to be considered as truly compatible with the API.
Plugins may or may not come with custom GUI plugins.
I don't think that either approach is going to work.
1) will fail because it makes all plugins but the simplest ones
non-portable. It also means that there is no way to connect plugins
in ways they're not explicitly designed for, except for on the basic
signal and control level, since there is no standard for how the
higher level interfaces work. That is, forget about controlling a
formant filter with a spectrum analyzer - the "spectrum" data type
would be non-standard...
2) will fail either on the host side - next to infinite complexity
and/or countless number of data format support plugins, or on the
plugin side - no way of getting the job done, as you can't get your
non-standard GUI interaction data through the API (which is the only
way to communicate with processing plugins).
I think the sensible way, that could work in real life, is some
middle way solution. There has to be some basic, generally usable
data formats that all hosts have to support either natively, or
through the use of converter plugins. (Data formats should probably be
divided into some classes; forcing all plugins to support both audio
and video isn't too sensible... :-)
There also has to be support for non-standard data formats. These
formats should, of course, be usable when connect plugins that come
from the same vendor (which in most cases would mean process <-> GUI
plugin connections), but there should be no point in connecting to
other plugins. If there is, the format should be considered a
standard, so that others can support it as well. (NOTE: This does not
have to affect hosts! It's a plugin issue only, as only plugins
really need to understand the data formats.)
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST