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 - 17:46:36 EEST
Steve Harris wrote:
>Maybe theres some way jack apps could indicate "child" apps, that would
>help a patchbay hide or group them.
subgraphs that look like plugins/clients which can be
expanded/collapsed in the patchbay might be a reasonable solution.
>Some things that would need to be solved, at some point:
>
> 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.
> Graph state. Some way of storing and restoring the (sub-)graph state. This
>was discussed here a few weeks back. I can't remeber the outcome.
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.
> Toolkit issues. You allready proposed a solution to that, but it needs
>implementing.
yep. to work smoothly and without much performance loss, applications
would need to become shared objects runnable by jackd. likewise, the
audio driver should become an 'ordinary' client (albeit the only one
acting as an 'audio clock' for the main graph).
> In process jack clients. For efficiency. Though OP clients for
>segfault-safe testing sounds like heaven :)
i was thinking along exactly the same lines. :)
> ...?
* common timebase (audio frames <-> 'real' <-> 'musical' time).
* 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.
* ...?
tim
This archive was generated by hypermail 2b28 : Wed Sep 04 2002 - 18:03:51 EEST