Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Stephane Conversy (Stephane.Conversy_AT_lri.fr)
Date: Thu May 25 2000 - 12:12:11 EEST
Erik Steffl wrote:
> 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
These are not plug-ins, in the sense that they do not transform data and pass
them to another plugin. A wave editor is a wave editor: it will eventually
use an oscillator plug-in, with the data drawn by the user.
> 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), ...
>
Ok, but let a different project handle it i.e. LMidiDSPA. Midi is just control,
that is the audio-network is completely seperated from Midi events chain.
I think we should keep things simple and seperated.
>
> 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.
>
good point, it's exaclty where we have a different point of view.
>
> 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...
The problem is that by enabling one to embed the oscilloscope gui in
ladspa, you force everyone to compile and install stuff about gui
even if it's useless for her.
Example: me. I use audio synthesis to design auditory interfaces, it's not musical,
and users don't have to use an oscilloscope, since their focus of interest
is not the audio per se.
In fact, I was engaged in Paul's Quasimodo project. The very reason was that
Paul was trying to make csound opcodes run in real-time.
When we were closed to something running, I tried to make quasimodo a server,
for my own purpose, for 2 reasons:
I wanted to use my own gui, because 1) Gtk-- takes toooooo long much time
to compile. 2) I wanted another kind of gui (written with Python/Tk)
I wanted to use quasimodo without a gui at all, because regular app would produce
sounds as an AUI.
You know, the more important problem with quasimodo right now lies in the fact
that it's really difficult to install, because of the large number of libraries
it requires. I feel it's something happening with ladpsa and the gui discussion.
> 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.
>
yes, I can still do 2), but I have to compile and install one's gui, whatever it is.
not vive-versa, I don't understand. You can always keep things seperated,
in other words, a model and a view. Let's implement the model in ladspa,
and the gui in another lib.
I would be glad to try and design an audio plug-in that you think requires a gui,
and make it split into two components.
regards,
PS: about the 'everything pluggable' paradigm: it's not a bad idea, but you're
are trying to design a flow visual language, which I think is beyond
the scope of the project.
-- Stéphane Conversy http://www-ihm.lri.fr/~conversy/ mailto:conversy_AT_lri.fr
This archive was generated by hypermail 2b28 : Thu May 25 2000 - 16:35:08 EEST