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
