Re: [linux-audio-dev] ladspa GUI round 2

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

Subject: Re: [linux-audio-dev] ladspa GUI round 2
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Thu Apr 05 2001 - 02:14:24 EEST


Sorry, only just had a chance to reply to this. My machine has been
offline for upgrades.

On Mon, Apr 02, 2001 at 11:03:18PM +0100, Richard W.E. Furse wrote:
 
> CONTROL VIA OSC, MIDI ETC
>
> I'm a little nervous about insisting on use of OSC. If it is enough of a
> standard this is fine by me, but it sounds a little heavy handed (string

> I've not looked at OSC so I don't know if it handles plugin start up,
> shutdown, audio streaming etc. If it does then we could do the above now
> for a GUI host using Paul's XML spec :-)

No, its just for message / parameter passing. I've been playing with the
example code over the last few days, and to be honest I'm not sure its
the right thing, its very complicated and has major portability problems.
However it is pretty well defined.

I still believe that string passing is neccesary for file loading etc. And
that the GUI needs to be able to deal in comms with the DSP plugin that
can't be expressed in LADSPA ports. I am open to being convinced otherwise
however.
 
> HOW THE GUI IS HOSTED

> 1. How does the host know what GUI plugins are available?

Thats still an open question as far as I know.

> 2. How does the host wire the plugins, start/stop them, send/receive
> control values etc? (Paul's suggestion and OSC and a number of other
> approaches could work as a basis here.)

I was imagining that hte host would still have control over all of these
and the GUI would just change ports and maybe od other comms with the DSP
part.

> 3. When does everything happen? How does operation differ when running
> offline to when running live?

It doesn't as far as I'm concerned. There should be nothing stopping a GUI
from being used even if it is not connected to a DSP part.

> 4. Does the plugin exist within the host's GUI or externally? ... and how?

Externally. It is running in its own process, so it has it own connection
to the X server (if thats what it wants, could equally be doing MIDI
things or whatever)

> E [executable]. Plugins exist in a common directory as binary files that
> can be run to extract parameter/configuration information and then executed
> by hosts locally or remotely. Communication is then maintained using OSC,
> IPC, sockets or pipes to stdin/stdout. This could be quite fast and makes
> the multitasking aspect explicit. Problems:
> i. The overhead for host and plugin design might be quite significant
> (although a library of standard plugin code could be provided).

I haven't tried to measure this, but I supect it isn;t that bad, given
that a user is not going to have a large number of GUIs open at one time.

> ii. Relatively high programming complexity.

Actually its pretty simple, I made a simple GUI of this form in very
little time, wiring it to OSC however was quite a task.

> iii. Different plugins will have very different look-and-feel and using a
> number will make the plethora of Windows confusing rather quickly. (Which
> one is wired to which? Which compressor is associated with track 19? etc.
> etc.)

I think this is a problem no matter what approach you take, I think that
the host will have to label the GUIs (string hint for title?) to make it
possible to distinguish them.

The variety seems like a good thing ot me, the point is that a gui
suitable for a compressor is not useful for an EQ, and providing widgets
for all the possible interfaces desired is too big a job.

> v. Potentially high start-up cost (relatively).

This is certainly true, I don't know if it will be an issue or not though.

> vi. Makes me nervous for other reasons I've not put my finger on yet.

Fair enough ;) Seems like the right thing to me, leaves the GUI designer a
free hand to do whatever they want, and the user a free hand to use
whatever GUI they want.
 
> SOME TEST CASES

I'l argue these in favour of the seperate process + OSC approach...
 
> A working API should ideally handle all the following (somewhat random)
> cases. Standardised wrappers for the existing LADSPA layer are required for
> a couple of them (e.g. a MIDI Sysex convention), but nothing controversial.
>
> Some hosts (imaginary, any similarities coincidental etc etc):
>
> 1. Rackmount 386 FX processor with custom low-latency kernel, small
> graphical LCD display and no X-Window.

The seperate process approach would work well here (SDL + bitmaps or
whatever). Only one GUI process would be runnign at any one time, and you
are free to use whatever drawing library you like. Of course the GUI would
need to be coded specially, but I htink that is unavoidable.

> 2. The above, but without the LCD display. Has MIDI though...

Ditto, but the GUI is infact MIDI CC's or whatever.

...the others I can't see the problem or are more host issues.

> 6. The host system has a core that runs on a remote Sun box while its GUI
> component runs and displays on a local machine over a busy network (while
> streaming audio & video for a gig).

This could be achieved either via X (running the GUI processes on the sun
and dipslaying on a remote x server, or by running the GUI processes on
the remote machien and connecting via OSC.
 
> Some plugins:
>
> 5. Audio plugin is a 512 channel spectrum analyser, GUI plugin is to
> display these on meters.

I nice implementation would be using control outs from the DSP part and
rendering those values graphically.

> 6. Audio plugin is a synth with four different FM configurations and eight
> envelope generators, all of which require graphical editors with five
> breakpoints.

You could build a paged GUI with whatever toolkit took your fancy.

> 7. Audio plugin is a complex general purpose filter with two GUI plugins.
> The first GUI plugin has just a cutoff frequency and resonance and sets the
> filter coefficients to operate as a Moog-style resonant low-pass filter.
> The second GUI plugin presents vowel diagrams to the user and sets the
> filter coefficients to generate the appropriate formants.

This is where its gets a bit vague, we havn't really discussed how the
hosts finds GUI binaries that are used with a given DSP plugin.

- Steve


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

This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 16:00:26 EEST