Re: [linux-audio-dev] ladspa GUI spec status?

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

Subject: Re: [linux-audio-dev] ladspa GUI spec status?
From: David Olofson (david_AT_gardena.net)
Date: Thu Feb 22 2001 - 23:49:06 EET


On Thursday 22 February 2001 12:12, Robert Jonsson wrote:
> ..Steve Harris wrote:
> > On Thu, Feb 22, 2001 at 03:32:14PM +1100, Conrad Parker wrote:
> >> yup -- any X program can be embedded in another, this is a
> >> feature of X11 (reparenting, in X11-speak).
> >
> > I was actually thinking of a completly independent window from
> > the app, but that was interesting, thanks.
> >
> > I have an idea for a plugin that needs to load a pcm file when it
> > starts, poping up a file load diaglog is the only sane thing I
> > could think of.
> >
> > Other things I thought of were setting an environment variable
> > (yuk), or always loading from, say /tmp/sampleN.wav where n is a
> > plugin parameter (also yuk), or combinations of the two.
>
> I would vote for a config file. The config file could contain a
> whole bunch of wave files. When using the plugin you could choose
> between them with one of the parameters.

How about keeping the file selector (although it's basically a cludge
from the plugin API POV), but only popping it up if you select a file
name that isn't in the config file?

> If using a GUI approach and many plugs where instantiated at the
> same time it could easily become unbearable. For instance during
> loading of a song...

With the above hack, the plugin would just shut up and load the
specified file when the "file index" parameter is changed. Quite
similar to a sampler, although it'll directly ask for a file when
you're trying to select a "patch" that isn't defined.

> Also I'm mildly sceptic to gui toolkit dependencies INSIDE of a
> plugin.

So am I. From a plugin POV, it sucks, but as LADSPA doesn't have the
interfaces required for requesting the host to load a file from disk
and make it available to the plugin, there's not much point in
throwing in "string ports" - and fixing both issues in a useful way
would probably eliminate the "S".

I could be wrong, though - if a generic and simple API enough could
be designed, it might make sense to throw it in...

> Aren't GUI toolkits mutually exclusive? Atleast I don't
> think it's possible to link against both gtk and qt in the same
> program.... should that not also apply to plugins??

Why not? Name conflicts? (Would be strange, as Qt is C++ with the
usual name mangling, I think...)

The "hidden" event loop of most toolkits can be a problem, though.
You probably have to run the GUI in a separate thread, unless you can
put up with the window behaving worse than a Windows modal dialog...

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david_AT_linuxdj.com -'


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

This archive was generated by hypermail 2b28 : Fri Feb 23 2001 - 00:23:35 EET