Re: [linux-audio-dev] ladspa plugin GUI proposal

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Thu May 25 2000 - 18:25:36 EEST


David Benson wrote:
>
> > Except: I'm in interested in getting musicians and sound engineers to
> > use Linux. When faced with the VST GUI for Freeverb, and the one
> ...
>
> I completely agree, except I am also interested
> in winning over plugin authors and host authors. So it is important
> to make the gui stuff optional and convenient, all around.

  exactly. plugins that do not have important visual function (like my
favourite oscilloscope:-) should all be usable with host generated gui
(based on parameters/hints).

> Let me try to summarize what I've heard of the gui dialog.
>
> it is clear that:
>
> - it would be nice to have standardized way to design
> guis for ladspa plugins.
> - it would be nice to be as toolkit / environment independant
> as possible.
>
> Many other questions have been raised:
>
> - should the plugin should make the gui,
> or should the host make the gui, or
> must both be allowed?

  I'd say both, with host generated gui being more important (we're
talking about primarily audio plugins, so it is important to be able to
just create plugin and not to have to worry about gui (if one does not
want to))

> - if the host makes the gui,
> how are the necessary hints (output controls) communicated
> from the plugin?
>
> - how can a plugin-made gui coexist with
> the host's gui?

  this is the critical question (IMO)

> - should be gui and dsp parts of the plugins be separated?
> (eg must they be in the same address space?)
> should they be optionally separated?

  that depends on what kind of performance we need.

> - should the standard define an API,
> or an XML or other data standard with rough
> implementations for various guis?
> both?

  my take on this is that XML should be the defualt (if possible),
forking off separate gui program when absolutely neccessary (but then
plugin and its gui use IPC which brings us back to performance issues)

> I've heard rough support for:
>
> - i think shared library considerations may
> force us to separate the libraries,
> even if we define a lightweight gui library,
> the host will be required to implement it if
> it wants to load plugins that link against that
> interface.
> (i'd advocate this separation on other grounds anyway)
>
> - xml-defined gui with possible plugin override.
>
> This would be good: it would mostly boil down to a DTD.
>
> Comments?
>
> - Dave


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu May 25 2000 - 21:18:55 EEST