Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Thu May 25 2000 - 20:05:40 EEST
Stephane Conversy wrote:
>
> 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.
see my other post (danger of do-it-all) for better explanation of what
I mean, I also back-up a bit from the requirement for gui to be
plug-able
> 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.
then you don't have to use oscilloscope plugin, since plugins are
dynamically linked you don't have to have any extra stuff...
> 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.
yes, that's the desired goal: for most of the plugins the host can
create ui, only special plugins that are _very_ visual would create it's
own ui (again, see my other post for more details).
> 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.
well, that's life. if you have many tools that each perform specific
function, you have, err... many tools. there's no way around it. the
solution is to have a system that automatically checks for dependencies
(debian is really good at this, redhat does have at least some of the
same functionality). and of course, have all the required tools
available as packages for given system.
> > 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.
no, you don't.
> 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.
yes, I was saying that we need to specify both, not they they have to
be one and the same.
> 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.
I was more concerned about the performance of IPC versus
within-one-application. but I gave up on that...
erik
This archive was generated by hypermail 2b28 : Fri May 26 2000 - 01:59:05 EEST