Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: Paul Sladen (paul_AT_sladen.org)
Date: Tue Nov 28 2000 - 11:09:38 EET
On Mon, 27 Nov 2000, Benno Senoner wrote:
> On Mon, 27 Nov 2000, Steve Harris wrote:
> > On Sat, Nov 25, 2000 at 12:50:38PM +0000, Paul Sladen wrote:
> > > On Fri, 24 Nov 2000, Paul Barton-Davis wrote:
> > >
> > > > As far as I am concerned, this is a broken model. Plugins should use
> > > > ONE standard data type.
> >
> > Heah hear, and I'm, not just saying that to be lazy ;)
> >
> > I would argue for MIDI streams (preparsed or not) though. Given a UI you
> > could easily make a synth out of LADSPA.
>
> I believe the best thing is to keep LADSPA simple thus not integrating this
> synth & co stuff.
> I like David Olofson's quotes:
> "LADSPA is VST1.0 done right, MAIA will be VST2.0 done right".
On this whole episode, haven't we got:
LADSPA
A simple, streaming plugin API using fixed data types and rates
LADSPA-GUI
xml descriptors using a [arbitary] widget set, /with/ set
dimensions.
LADSOMETHING
An interface for allowing disperate programs to expose a set of
functions to be run in a single RT or non-RT SCHED_FIFO process for
with support for multiple data rates, and formats.
A *fully functional* interface that is extensible enough to allow
for extensions, now, or in the future. (H/W Abstraction?).
LADSOMETHING-XML
An xml spec for saying what ports a plugin supports.... or particular
.so of multiple plugs supports.
LADSOMETHING-NET-MANAGER
A library (plus simple/generic example application) for plugining
together and modifing the net ("user-space" version if you like -- it
should imform/talk to the audio-server, either via the messaging
archetiure, or directlly, that it needs to unplug, or re-plug this or
that connection -- the audio server and then test to see whether this
is valid and insert patch-ups (ie conversion plugs) if it is not.
LADSOMETHING-AUDIO-SERVER
An API for allowing LADSOMETHING .so applications to be plugged
together and run in a single thread. Responsible for managing
module initisation and low-level net managment and possible support
for message passing and breaking down of messages. Raw messages
passed to RT thread for execution ASAP RT.
LADSOMETHING-MESSAGE-SERVER
An API responsible for proxying, and brokering message passing
(mainly) between RT audio, and non-RT (possibley external) GUI
elements addhering to one of its two interfaces.
At least one copy of the server running on each machine. If need be,
should provide /routing/ by a suitable network protocol.
A suitable network protocol might be UDP, custom ethernet packets, or
serial link to palm pilot... (the message protocol could be MIDI for
all I care).
Interface to LADSOMETHING-AUDIO-SERVER, and an API for GUI elements,
and/or other external control/feedback elements.
LADSOMETHING-GUI-LIB
A GUI providing a set of useful widgets, pots, sliders.
Possible backends: gtk, ardour-definition, Palm, Xt, Lego RCX ;-)
LADSOMETHING-GUI-INTERFACE
An interface definition for widgets to provide a .so based custom GUI
controls. Should /not/ use any form of communiction with RT thread,
expect via published control (port) interface... though messaging
server.
A final addition to this would be a LADSOMETHING-GUI-INTERFACE client
capable of reading the XML port definition files, and (itteligently)
layouting a suitable interface pesentation to the user.
Tear this to pieces so I can get my head into line with everything that is
ahappening.
Paul
-- e: paul_AT_sladen.org t: 0115 922 7162
This archive was generated by hypermail 2b28 : Tue Nov 28 2000 - 12:00:17 EET