[linux-audio-user] jack-rack wish-list

[Christoph Eckert]

Several days ago (20050612) Lars Luthman wrote:

> > The situation is getting worse if you use more than one
> > app and you have to restart JACK itself. Then you have to
> > reload a lot of files into all applications and to redo a
> > lot of MIDI and JACK connections. If each particular
> > application could (maybe optionally) remember
> >
> > * the last loaded file
> > * the last used MIDI connections
> > * the last used JACK connections
>
> This is what LADCCA (LASH) is for. You start your programs,
> do your connections, and tell LADCCA to save the project.
> Later, when you ask LADCCA to restore the project, it will
> start the same programs, make the connections, and tell the
> programs to load their states from the project. There
> haven't been any new LADCCA releases in a while, but 0.4.0
> works quite well for things like this.

Yeah, it's cool. But I still think that my ideas could improve 
users' impression when dealing with free audio software for 
the following reasons:

* Audio applications can crash, and if - at this time - LASH 
didn't already save the configuration it's lost

* Maybe someone simply installs jack-rack and some LADSPAS to 
use the box as an effects rack. What happens if LASH doesn't 
get installed? An audio application shouldn't depend 
necessarily on LASH, but use it as soon as it is available

* Others may prefer to not install LASH because there's no 
package for the distro or even the user has no (root) access 
on the machine, so the above is still valid.

> The problem is that only a handful of programs support
> LADCCA - which is strange, because for a typical program
> that already has functions to write and restore its state
> from a file you only need a few dozen lines of code to make
> it work. Call the initialisation function and tell LADCCA
> your JACK name and ALSA ID when you start the program, and
> write a timeout callback that checks for new LADCCA events
> a few times every second (Save, Restore, and Quit should be
> sufficient for most programs) - and that's it.
>
> http://lash-audio-session-handler.org

OK, but then users can write feature requests for the 
particular applications.


I think the following could be a flexible solution:

* As soon as an application starts it checks for a running 
LASH server
* If there is one it behaves as told by LASH
* If there is no LASH, it could read the last used document 
and the last used MIDI and audio connections from the config 
file
* As soon as the document file or any connection changes, an 
application could immediately write it back to the 
configuration file so even a crash will cause it to reload 
the settings when it gest restarted


Even at the Linuxtag show this was sometimes a show stopper. 
Zyn crashed and after restarting it you have to redo all 
connections manually and to reload the last used patch while 
the 'customer' is watching ;-) .


Best regards


    ce