Subject: [linux-audio-dev] Re: ladspa plugin GUI proposal
From: Maurizio De Cecco (maurizio_AT_mandrakesoft.com)
Date: Thu May 25 2000 - 12:48:21 EEST
A quick answer on a couple of points, but i'll write a more
complete mail later, addressing what is IMHO the real point
to discuss.
Paul Barton-Davis <pbd_AT_op.net> writes:
> >Not by definition, it is a design choice.. Why you assume a scenario
> >where the DSP plug-in is the master and have all the knowledge ?
>
> Because there is plenty of evidence before my eyes that one of the key
> elements of writing good DSP plugins is creating really good GUI's to
> do with them.
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.
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.
So, when i say that the LADSPA API should not talk about GUI at all,
i just means that 2) do not have anything to do with the GUI; but then
1) may include one or more GUI, as you like.
> >It is the application after all that load (or ask loading) the plug-in,
> >the same application may decide which GUI module to load, and when.
>
> When you ask a plumber with 30 years experience into your house to fix
> the pipes, do you plan to tell him what to wear and what tools to
> bring ? The plugins are the masters of their domain, and you need to
> show them some respect :)
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.
> We can limit the scope, just as Steinberg did with vstGUI. This *is* a
> solved problem, at least if the limitations on the widget set are not
> too restrictive.
[ ... ]
> We're solving this with variations on the XML idea, perhaps.
I'll answer in the next mail.
>
> 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 ?
> I agree. This is why I like something along the lines of vstGUI, but
> specified in XML rather than C++, so that it can be implemented by
> whatever toolkit the host uses, or without it, or whatever.
vstGUI (or any kind of LADSPA-GUI) for me is the wrong decision, for reasons
that'll explain in the next mail.
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.
This does not means that it should not be done (otherwise, we would have
no innovation in open source :-), but it means that it should be done
as a separate project.
Also, anything like this should go in the 1) context, i.e. not part
of LADSPA API and not part of the 2) library.
Maurizio
-- Maurizio De Cecco MandrakeSoft http://www.mandrakesoft.com/
This archive was generated by hypermail 2b28 : Thu May 25 2000 - 17:24:22 EEST