On Sun, Jan 31, 2016 at 9:59 PM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
On Sun, Jan 31, 2016 at 3:48 PM, Kjetil Matheussen <
k.s.matheussen(a)gmail.com> wrote:
On Sun, Jan 31, 2016 at 2:44 PM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen <
k.s.matheussen(a)gmail.com> wrote:
I don't think Jack is the wrong solution for a DAW either. But Jack
never got finished.
It has a wonderful API, but it shouldn't be a struggle for a program to
create a jack client
if a jack server isn't running. (there were a lot of talk about this
around 10 years ago,
but the end result never became as good as it should I think).
i am not sure what the problem is here. if the client doesn't specify
anything, then the server will start automatically with the same parameters
as it did last time. this has worked for years. no?
Well, I've never used it. It doesn't feel safe. There is no obvious place
to
check that it does what it's supposed to.
You're sure of that? Every one of your JACK clients explicitly avoids
auto-start?
I think so too, but I meant to say that, as a user, I always start jackd
first since I don't want
to risk a client to start jackd in a way I don't feel sure about.
The mechanism for this is extremely simple and robust.
The contents of the
file ~/.jackdrc are executed. You can check the result with ps aux or a
graphical equivalent.
It would be better if this information was available in a function in
libjack so that
clients can show what's happening.
, plus that it
would provide an enormous number of fun and interesting programming
challenges
for the implementors of that functionality.
and no effective difference for users over and above the current
auto-start scenario.
you also missed out how EVERY single possible JACK client now has to have
some way to bring up a server control dialog, that will work no matter what
GUI toolkit the client was written with (or no GUI toolkit).
is this supposed to be a serious suggestion?
Yes. First you imagine what would be perfect. Later we can worry about
reality.