26 Jun
2005
26 Jun
'05
7:16 p.m.
Several days ago (20050612) Lars Luthman wrote:
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 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. 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