Re: [Jack-Devel] stepping down

On Sun, Jan 31, 2016 at 5:12 AM, Spencer Russell <[hidden]> wrote:

>
> I agree JACK probably isn’t the right solution for your basic DAW user.
> That said, I think there’s great value in the general paradigm of
> separating the routing from the applications. As an application developer,
> it’s great to just expose your ports and make routing Somebody Else’s
> Problem.
>
>
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 think the first program trying to create a client also should start the
server. Not
just fork off a process, but actually run the server.
And if another program wants to create a jack client, it connects to the
first client process,
which is the one running the server.

Furthermore, GUI should be built into libjack, so that you can call
jack_open_audio_driver_configuration_gui(),
jack_open_audio_connection_configuration_gui(),
etc. inside your client.

I know there is something called libjackserver, but how many uses it? Does
it do
all these things? How stable is it? In my opinion, there shouldn't
be any libjackserver, or jackd program, or qjackctl, only libjack.

Another problem with Jack is that it never attempted to do consumer audio,
and then we got pulseaudio in addition to Jack. There should only be Jack,
IMO.

1454239994.3402_0.ltw:2, <CAC6niEJY5Y66S_BTytwQD=gtmowVwwr_=+nsqqxfXnYdQNr2qw at mail dot gmail dot com>