OK,
> And your favorite is... ?
you asked for it :) .
Some things which I'd really appreciate:
* Applications could remember tha last used MIDI and JACK
connections as well as the last used file and resetup
itselves when getting restarted. Applications could write
these infos to the config file as soon as connections are
made and a file gets saved/opened, so a crashing application
can still remember these things. This is something which fits
to Dave's request and can reduce the need of LASH
* When JACK gets restarted it would be great if running JACK
applications wouldn't need to be restarted. Perhaps it would
be possible to teach them to bring an informational message
to the user that the connection to JACK has been lost (some
already do) and to reconnect automatically as soon as JACK
gets available again. I do not know how difficult this is
from the technical view but I guess it can be done. This also
fits the first issue and can also reduce the need for LASH
* Applications could complain via an alert box as soon as the
needed audio subsystem isn't available, e.g. JACK isn't
running or the ALSA device is blocked. ams simply doesn't
appear on the screen but is waiting in the RAM until the ALSA
device gets available. As soon the blocking application quits
ams appears on the screen. This is not only an ams issue, but
I made this experience with ams so it's an example
* Applications which can output sound to various audio
subsystems could offer an autodetection mechanism.
Example: Application Y can output sound via ALSA or JACK.
Invoking it without any parameter makes it running on top of
ALSA. To make it an JACK application, it needs the parameter
--jack.
I'd prefer the following behaviour:
If it is invoked without any parameter, it looks for JACK. If
JACK is running, it behaves as a JACK client. If not, it
tries to use ALSA. The autodetection can be avoided by
explicitely telling which system to use.
Examples:
Y --jack => makes it a JACK applicaton
Y --alsa => makes it an ALSA application
Y => does autodetection
Best regards
ce
Received on Mon Jun 20 00:15:23 2005
This archive was generated by hypermail 2.1.8 : Mon Jun 20 2005 - 00:15:24 EEST