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

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

Subject: [linux-audio-dev] Re: ladspa plugin GUI proposal
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu May 25 2000 - 17:58:56 EEST


>There is technical misunderstanding here; we may have two things here
>(i invent a terminology just to be clearer):
>
>1- The Plug-In Product, i.e. the things that is delivered to a user
> for the installation.
>
>2- The DSP Plug-In, i.e. a .so (or .a) library written to the
> LADSPA specification.
>
>1) and 2) do not needs to be the same thing; IMHO, 1 and 2 should
>*not* be the same thing.

Agreed.

>So, the fact that 1) should include a good API for the 2) do *not*
>means, technically speaking, that this API specification is included
>in 2, i.e. in the LADSPA module.

I don't believe that it will be possible to create *any* GUI system
without support from the LADSPA API.

>Right, i suppose that the emulation of an MPX-1 reverb front panel can be
>of great use to a game engine where the reverb is used for sound effects.
>
>Who understand the plug-in may not understand the context where the plug-in
>is used.

I've have said this MANY times: the host is free to COMPLETELY IGNORE
THE GUI PROVIDED BY THE PLUGIN.

My concern is not to provide a way for the plugin to always provide
its own UI. Its to provide a way for the plugin to provide a kick-ass
GUI when run in a host that allows this.

>> Because it won't work. What happens if the host uses FLTK ? or XForms?
>> Or wxWin ?
>
>And what if the user use tcl-tk, for which you did not wrote the XML
>engine; what if the user use the new Qt version, for which no XML engine
>exists already ?

Any host that has not implemented support for the putative
XML-described GUI *** CAN COMPLETELY IGNORE THE PLUGIN-PROVIDED GUI ***.

>I just want to remind you that what you are trying to do is a multiplaform
>tool-kit independent UI component system; nobody until now succed in doing
>anything vaguely like that; you are vastly under-estimating the difficulties
>in specifing such a think in way that could be actually usefull.

Actually, you're wrong because of an important detail. The reason why
this can (could) be done is because we are (could) limit the scope of
the visuals that can be displayed. With this caveat in place, both
Quasimodo and vstGUI stand as examples that have done "something
vaguely like this". We are not trying to create a toolkit independent
turing complete system, or even a toolkit independent thing that can
do everything that GTK, Qt, or any other GUI kit can. We're talking
about providing a relatively restricted set of display elements. Thats
a hugely important detail. Since one of the display elements includes
sets of pixmaps (in my proposal, anyway), this is not *much* of a
restriction on the visual appearance.

--p


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 - 22:46:10 EEST