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 - 22:36:52 EEST
Steve Harris wrote:
>I've had some experience of seperating GUI's and DSP code this way (from
>LCP) and its hard work, even for pretty simple things. Maybe a library could
>make it easier though, eg. automatically binding gtk_adjustments (or the
>toolkit X equivalent) to jack-plugin control ports...
if the adjustment directly modifies the port value, the port itself
needs to emit a 'changed' event. either this or a list of clients
that want to receive a notification when a port value changes.
that's a complication that i'd like to avoid, but i admit it's not
easier with the sequencer between gui and plugin either, although
in that case the sequencer playback could be directed at both the
gui and the processor.
if the gui polls the current port value periodically any way works.
>There needs to be a standard, so the the "host" can force them to store
>thier state somewhere it can archive it, record the graph and dump the
>whole lot to disk. I dont think that just recording the last automation
>data is enough, eg. for a looper "plugin" that would like to record the
>contents of its buffers.
agree. it boils down to making a client emit 'serialized' instance
state data, and restore its state from this data. the who and where
of persistent storage is another problem. you're right in that it
would better be done by the graph maintainer though.
>> * common timebase (audio frames <-> 'real' <-> 'musical' time).
>
>Jack does this allready.
for musical time, based on ticks and a tempo map? if your version
of jack does this, you should commit your changes to CVS. ;)
>> * lock-free, cross-process, cross-client event/object communication.
>> this is a tough one especially if events/objects can be of arbitrary
>> size. maybe a proof-of-concept implementation could use fifos/
>> AF_UNIX sockets here initially. eventually i think one will need to
>> use shm like audio signal transport already does.
>
>Like Paul said, it needs someone to implement a malloc-alike for jack.
>Tricky, but not impossible.
a possible halfway solution:
* client (or jackd when initializing) registers a new sized & named
object type.
* libjackd allocates a shm segment containing an array of n instances
of the data type, where n is a hard limit from then on.
* whenever such an object is to be emitted, jackd fetches it from the
'cache' shm segment. the object is referenced by type and index into
the type cache, so it is usable cross-process, and because it's
cached it is realtime capable for free.
* the client/plugin that eventually 'consumes' the object returns it
to the cache.
that doesn't solve the generic malloc problem (strings of arbitrary
size) but it does look attractive for the common case of fixed-size
events.
>I'm not 100% sure that using the jack audio data graph for this is optimal
>(it will complicate the graph and maybe make it difficult to pick a good
>low-latency ordering), but I also haven't thought about it hard enough.
not sure either. two or more graphs will make it more complicated for
the user en tout cas.
tim
This archive was generated by hypermail 2b28 : Wed Sep 04 2002 - 22:54:25 EEST