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 - 21:57:34 EEST


Stephane Conversy wrote:
>
> Erik Steffl wrote:
>
> > 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
>
> do you have any other examples like this one?

  of course (some of these were already mentioned by others): wave
editor, any plugin that does the same as winamp plugins (visualisation),
plugins that have non standard/complicated controls like a pad/pan, note
editor (I know that as of now we're talking audio data but I hope sooner
or later midi and other types of data will be added), ...

> > B: simply fancy buttons.
> >
> > while we might ignore the B (not nice, but it might prove acceptable)
> > we (IMO) should not ignore A.
> >
> > erik
>
> no we shouldn't, but only if it's really useful. An oscilloscope is not a plugin,
> it's a gui element that tracks the result of a plugin.

  well, that's up to decision, it looks like the experience with vst
shows that there are plugins whose main functionality requires visual
part.

  there is a design choice to make:

  1) host is (can be) generic, all application specific code is in
plugins

  2) host is some specific application that uses plugins for very
specific (=dsp) purposes.

  I would advocate choice 1), which means that the plugin API will be
more complex but very useful, because you could easily build any
application by simply connecting various plugins. that's why I advocate
suport for ports of various types etc...

  an oscilloscope example: I would like to be able to take the
oscilloscope plugin and connect it to the rest of the system, or
possibly take oscilloscope-audio and oscilloscope-gui plugins... I don't
say that audio and gui has to be meshed together, but both audio and
gui should be 'plug-able', otherwise the oscilloscope is useless, if I
have to code the gui for it...

  of course the S in LADSPA suggests that original intent was probably
closer to 2)

  note that if LADSPA is designed as described in 1) you can still do 2)
but not vice versa.

        erik

>
> >
> > Maurizio De Cecco wrote:
> >
> > > 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.
> >
>
> I completely agree, I want to have plugins that compile fast, and without
> taking care of any ui toolkit.
> If some of you agree on a GUI toolkit, write it, but don't embed
> the code into the dsp code.
>
> Benno Senoner wrote:
>
> > my thoughts:
> >
> > split the plugin into 2 .so files
> > one .so for DSP work, the other .so file for the
> > GUI editor.
> > eg. filter.so and filtergui.so (written in gtk)
> > The gtk-process will load the filtergui.so code
> > and execute it happily.
> > If the main host has to communicate with the
> > editors, do this via IPC shared mem
> > or using the shared memory provided by threads.
> >
>
> This is something better in my opinion.
> Let the dsp code be portable, simple to compile, and simple to
> access with my own gui. If you agree on a particular gui, make people know it, but
>
> don't mix dsp and gui code (exception: gui hints), let others use plugins as they
> are designed to: producing audio.
>
> In sum: I want a ladspa.tar.gz and a ladspa-main-gui.tar.gz.
>
> stef
>
> --
> Stéphane Conversy
> http://www-ihm.lri.fr/~conversy/
> mailto:conversy_AT_lri.fr


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 - 00:59:48 EEST