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: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Wed Sep 04 2002 - 18:51:21 EEST


On Wed, Sep 04, 2002 at 04:46:36 +0200, Tim Goetze wrote:
> > Automation. Sequencers and the like need a way of recording user activity
> >in these uber-plugins. LADSPA makes this very easy.
>
> afaics, this can be solved by inserting a recording/playback plugin
> between gui and processor client/plugin. can also be a proxy inserted
> there by a 'real' sequencer application.

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...
 
> eventually needs all clients/plugins to save and restore their state
> themselves. simpler plugins could use a default mechanism that knows
> only how to instantiate them and how to save/restore port states. if
> port states are object-wrapped, coding this default mechanism is
> greatly simplified.

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.
 
> * common timebase (audio frames <-> 'real' <-> 'musical' time).

Jack does this allready.
 
> * 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.

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.

- Steve


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 - 19:03:48 EEST