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
