25 Aug
2017
25 Aug
'17
2:26 p.m.
On Fri, 25 Aug 2017 10:24:43 -0700, Yuri wrote:
A stable environment for professional usage should be a stable
environment. The premiss that you still could continue a gig, if the
virtual B-3 crashes, as long as the virtual Rhodes continues working, is
a wrong premiss. Nothing should ever crash, if it should, it's an
accident, an exceptional situation. Apps that tend to crash on a
regular basis aren't usable for pro-audio. Again, if jackd could be
improved to fit to your needs, without side-effects for what jackd is
intended to do, it's good. But what you describe isn't a major problem
of jackd. Most users don't experience it.
On Fri, 25 Aug 2017 19:41:00 +0200, David Kastrup wrote:
Because I am not in a production environment. I
experiment, and need
to stop looped scripts.
Consider that if jackd would include all kinds of protection measures,
the risk of false positives could increase. For experimental circuits
you would use a fast acting fuse, but for the finished circuit you
would use the slow blow fuse. Jackd is a sound server aimed for
pro-audio usage, not for desktop sound, not for experimental usage, at
least not by using default settings. For experimental usage you should
be willing to kill jackd.
Even if jackd
should need the improvement you requested, consider to
do such things in a logical order, as you would do when using
expensive hardware in an audio studio. You wouldn't pull on a cable,
to unplug a
This is a major problem with Jack, because clients can crash or be
killed and this likely renders jack server unusable. It doesn't matter. There is no point in Jackd
being dependent on other
applications' behavior for sensible behavior of its own, most
particularly not on particular procedures for their termination.
Unless they have explicitly set up actions to be taken after their
termination (connecting Jack ports may count among that set: it might
be an idea to require applications to mark its connections explicitly
if it wants them to stay around after finishing, like jack_connect
obviously would), Jackd should just revert to a "virgin" state when
they terminate.
You are assuming absolutely clear situations and in my experiences
jackd does the right thing regarding the described issue, if nothing is
fishy. As soon as something is fishy, it's not that easy to decide what
is the right thing.
You know: mixers that start with a _huuuuuge_ switch-on
bump blowing
out the bass speakers and waking all the neighbors are badly
designed. Yes, one can work even with badly designed equipment, but
there is no real necessity of making Jack badly designed for
educational purposes.
A a careful audio engineer would always use a sane order to turn on
equipment, even if the equipment should provide all kinds of protection
measures.
Regards,
Ralf