[linux-audio-dev] LADSPA extension mechanisms

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

Subject: [linux-audio-dev] LADSPA extension mechanisms
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Sun Apr 08 2001 - 13:42:44 EEST


Daniel V. wrote:
> I don't think it's a bad idea, but similarly I don't think it will be
> implemented because LADSPA's simplicity is it's strength. You don't
> want to be in the situation where things get ugly, but you can't fix
> the spec because you have lots of legacy apps relying on the ugly stuff
> (see: dos). You're probably better off using your own slightly modified
> spec that stays close to LADSPA, and encapsulate LADSPA in this spec at
> your end.

I think this is the approach I'll take - I'll make something that is
LADSPA-compatible in the simple cases, and accept LADSPA plugins into
my host, maximising the sharing that can happen. Whether my project
gets to see the light of day or not is another matter - I certainly
hope so.

> Can't see a way to solve the problem of getting
> your plugins to work with other hosts thru LADSPA though :(

There is a general problem which I've caught a whiff of from the
discussions here I've heard so far, and that is related to exactly the
same thing that I've been trying to do. Except in this case you've
been looking at GUIs and so on. There are two ways to go - either you
make the plugin talk to the GUI via its own custom private connection,
or you do it through some well-defined (but flexible) interface. That
interface may be OSC (perhaps), or some kind of extended-LADSPA, or
something else.

I would vote strongly against plugins using custom private interfaces
to their GUIs because this makes it impossible to record and replay
(or script) these changes in a generalised way.

=== Custom private interface (I don't like this)

                    +-------------------+
                    | LADSPA plugin |
   +--------+ | |
   | HOST |----> = LADSPA interface |
   +--------+ | | +-------+
                    | Custom interface = <----| GUI |
                    | | +-------+
                    +-------------------+

=== Public defined interface (better)

   +--------+ +-------------------+
   | HOST |--------------+ | LADSPA plugin |
   +--------+ | | |
       | | = LADSPA interface |
       | +-----> | |
   +--------+ | = Extended i/f [*] |
   | GUI |--------------+ | |
   +--------+ +-------------------+

   [* OSC (maybe), or some other extended interface ]

As to OSC, I'm not totally convinced by this standard. But this isn't
my decision anyway as my direction forwards is clear now, and I'm not
concerned about GUI development.

Also, I think GUI development should be independent of the plugins
themselves so that the plugins can be used without the GUI, or with
alternative GUIs, and also because some people are really good at
audio coding, and others are really good at GUI coding and design.
Just think of all the `skins' and front-ends that have been created
for applications like mpg123 and bladeenc.

For what it's worth -

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim_AT_aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk


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

This archive was generated by hypermail 2b28 : Sun Apr 08 2001 - 14:05:26 EEST