Subject: Re: [linux-audio-dev] emagic (logic) drops VST support under OS X
From: Tim Goetze (tim_AT_quitte.de)
Date: Tue Sep 03 2002 - 16:58:05 EEST
Steve Harris wrote:
>On Mon, Sep 02, 2002 at 06:22:33 +0200, Tim Goetze wrote:
>> i believe that with patience and prudence 'lad' may be capable of
>> producing an interface definition capable of connecting all our
>> audio/MIDI apps and libraries in style, without deriving from CA
>> or VST.
>
>I agree. Entirely. But I have some nagging doubts about this process
>
>1) its very slow. everyone wants to put thier oar in (including me ;) and
>there are always people who have subtly different ideas about what the
>goals are. Thinking back to the LADSPA 1.1 and jack discussions.
true. i think the only way out in situations like those is to accept
only ideas that everybody agrees on, because the common goal is that
everybody uses them, and that nobody needs to do the same thing
twice. that doesn't really speed up things though.
>2) I think we could miss out on an oportunity to be compatible with
>something or other.
being compatible we might miss an opportunity to be better than
something or other. ;)
>1) we can bias it towards our usage, eg. command line friendliness.
>LADSPA, owing to its use of meaningful port values is pretty commandline
>friendly.
>
>2) no licencing problems.
fully agree, and never had much sympathy for this license kind of
business either.
>Something that needs to be address in any LADPA format is the GUI issue.
>X really complicates this. You have to select one toolkit for inprocess
>plugins, and for practical and pollitical reasons its basicly impossible
>to pick Qt or GTK (...etc.). So, we need to agree on a plugin UI toolkit,
>it has somehow to be compatible with hosts toolkits and it has to be easy
>to write plugin guis in. Fun.
that's where out-of-process is our only hope of unification i think.
this or that some sunny day all of the toolkits agree on a common
divisor.
>This is something I'd hoped we might be able to get from AU's, as at least
>it would settle a lot of arguments about API style etc. Then we could get
>down to the (admittedly hard) process of supporting the API in peoples
>favourite toolkits.
if the Jack server turned into a library, it would be easy to write a
jackd, jackd-tk, a jackd-fltk, a jackd-qt, jackd-gtk, and load clients
into the 'jackd-x' server process if they agree on toolkit 'x' and are
.so themselves.
if they don't, they can still be run as separate processes, preferably
as jackd-y, which runs all clients that want toolkit y. otherwise this
jackd-y would be just an interface to the original jackd-x.
if plugins are only accessed through a jack interface, a post-LADSPA
'host' does not need to care about the plugin's toolkit preference.
a traditional libdl interface for communication among 'host' and
'plugin' clients is still available if they both are run within the
same process.
what i liked about the CA approach, and like about Jack, is the graph
idea. i think all the Jack graph lacks conceptually is the ability
to also transport timestamped, structured information among client
ports. (just dreaming away, i know that implementing this is more
than a day's work.)
i believe that if all clients agree to support as much of their
functionality as possible via ports receiving and sending such
information, a very powerful system can be built from very simple
components.
if all clients initially support a small tree of common named object
types, we might be able to create a simple ever-emerging API which
can express solutions in many problem spaces, leaves all authors
reasonably free and which will converge by evolution:
if clients are free to derive their own named types from this common
predefined tree ('float' value, 'string' value etc), exposing the
structure and purpose of the derivatives in a friendly and
human- (not necessarily machine-) readable form, useful clients will
get good support from other clients in short time, and their
particular interface development process can be decoupled from other
development processes. yet through inheriting from what is known, an
unknown interface can at least expect partial support in
'incompatible' clients that choose to allow such a connection.
it would be in their own interest that client authors keep these
interfaces simple, easy to use and consistent, yet after all it's left
to them alone to decide what to call, how to implement and when
to change them, and whether it might be wiser to mimick a similar
interface a similar jack plugin already provides.
yup. what do you think?
tim
This archive was generated by hypermail 2b28 : Tue Sep 03 2002 - 17:21:41 EEST