OK, heres a graph of how I think a simple plugins via jack session could look: http://www.ecs.soton.ac.uk/~swh/jack-plugin-graph.png
Control data is in red, audio data in black, and I know you can't have bidirectional jack connections, but it makes the diagram simpler ;) The apps are App A+B the DSP plugin clients are P1-4 and the gui clients are just labeled GUI. The subgraphs are SG X+Y, whether they are explicitly marked as such in jackd or not. The distinction between plguins and apps is purely subjective of course. Neither of the apps are capable of automation, as they dont have control lines going to the dsp components. The subgraphs make it more obvious how the state (re)store could work: * The user instructs jackd that they want to store the session * Jackd writes out /tmp/$$/jackd.state describing the connections between apps. * Jackd creates /tmp/$$/app_a/ and instructs App A to store its state there * App A writes out .../app_a/my.state, creates .../app_a/P1/ and instructs P1 to write its state there, rpt. for P2 etc. * Jackd creates /tmp/$$/app_b/ and instructs App B to store its state there * App B writes out .../app_b/my.state, creates .../app_a/P4/ ... * Jackd tars up /tmp/$$ and there you go. To restore, you just unstar to the state tarball, jackd launches the apps, passing in thier state directory, and they each launch thier subgraphs. Obviously this recurses, if for eg you have P5 that has a subgraph of its own. And the same mechanism can be used to save the state of a single apps plugin graph. - Steve
