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: Wed May 24 2000 - 19:12:45 EEST


  it looks like the reason gui is so important is that some plugins will
be audio/visual, not audio only.

  the visual part can be:

  A: part of core functionality (osciloscope) or
  B: simply fancy buttons.

  while we might ignore the B (not nice, but it might prove acceptable)
we (IMO) should not ignore A.

        erik

Maurizio De Cecco wrote:
>
> Paul Barton-Davis <pbd_AT_Op.Net> writes:
>
> > So, back to the drawing board. Either we have to provide the toolkit
> > layer (like the vstGUI library), or we specify the host's chosen
> > toolkit and have the plugin be required to use it. This last one is
> > pretty disgusting.
>
> I still don't understand why the plugin specification should include
> anything about the GUI.
>
> As the discussion prove, there is practically no way to do it so it
> would work with all the potential applications.
>
> It is a good design practice to separate UI from applicative code; why
> don't specify an API to access and potentially discover which
> parameters the plugin have to offer, and leave the UI and plug in problem
> separate ?
>
> The plugin may very well run in an environment *without* X windows
> (either an embedded audio application, or an audio processing server,
> for example); or it may run in an environment where the user inteface
> is *not* X Windows (framebuffer based toolkits, Berlin, whatever).
>
> The plugin may be usefull in an architecture where the processing and
> the interface run on different memory space, or may be linked together;
> and so on and so on ...
>
> My impression is that a plug-in API should be just that, a plug-in API,
> while forcing in the UI will put a severe number of constraints on
> the application itself.
>
> This does not means that plug-in should not have an Graphical User
> Interface; it means that the specification on how to do a GUI for a
> plug-in are a different things, that depends on many things the
> plug-in itself could not care less, like the use of GNOME or KDE.
>
> If we have a GUI-free API for the plugin, we can later define
> API for graphical plug in (or more safely use the already existing
> standards) for defining the plug in part of the UI architecture.
>
> Sure, if you want to use a plug-in in a given graphical environment
> you will be forced to develop a UI for that graphical environment;
> this is true for *any* software developement today, don't try to solve
> a problem that 30 years of GUI developement have not solved yet !
>
> Maurizio
>
> --
> Maurizio De Cecco
> MandrakeSoft http://www.mandrakesoft.com/


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

This archive was generated by hypermail 2b28 : Wed May 24 2000 - 19:58:04 EEST