Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)

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

Subject: Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)
From: Tim Goetze (tim_AT_quitte.de)
Date: Wed Sep 04 2002 - 00:26:04 EEST


Steve Harris wrote:

>On Tue, Sep 03, 2002 at 03:58:05 +0200, Tim Goetze wrote:
>
>[toolkit problem]
>
>> 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.
>
>Well, it is possible to write a plugin-specific common denominator. I have
>no idea how much work it would be and it would have to be written for
>every toolkit that people wanted to write hosts against.

agree, that would be great. it doesn't solve problems like running
for example both ardour (gtk) and muse (qt) under the same jackd
though.

>> 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.
>
>I think this would be a real headache to code, I'm still thinking along
>the lines of self contaitned .so-s that are dlloaded into a particular host
>and the graph is controlled by that host.

i'm not so sure it would be such a big problem to code -- jack is
very 'cross-process' by concept. the current jack graph can already
be thought of as 'shared' among and 'controlled' by all clients.

>> 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:
>
>Interesting idea. I'm not sure how it would pan out in reality. It might
>be a good match to the heavily distributed Free s/w development model, but
>it might also degenerate into chaos ;)

my hope is that everyone who writes for such an API avoids such
chaos out of their own interest. even if the system should evolve
towards chaos, one can always code an isolated 'converting' plugin/
client to make a particular client work in a particular setup. which
is still far better than to have no clue about how to connect
and endless discussions with nobody willing to give an inch. :)

>MIDI seems the be one thing there is a lot of requests for, and it would
>also be one of the hardest to agree on.

i don't think there's actually much left to discuss by the MIDI
standard itself. you have (except for realtime messages and sysex)
exactly 7 event types, with sizes ranging from 2-3 bytes. that's
MIDI by the letter, there's nothing more to it. i even find that
a single event type to hold all message flavours is sufficient.

tim


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

This archive was generated by hypermail 2b28 : Wed Sep 04 2002 - 00:39:03 EEST