Re: [Jack-Devel] stepping down

On Sun, Jan 31, 2016 at 11:10 PM, Paul Davis <[hidden]>
wrote:

>
>
> On Sun, Jan 31, 2016 at 4:50 PM, Kjetil Matheussen <
> [hidden]> wrote:
>
>>
>>
>> I meant server options. Driver name, realtime on/off, driver options,
>> timeout, etc.
>>
>
> why does a client want these? it would not contain code to start JACK that
> required any of this .... unless you're suggesting a different GUI to
> configure the server in every client, which you're not ...
>
>

You want to see which options jack has been started with. You want this
information
visible in an obvious way. It is both undocumented and flaky to have to
"run ps -Af|grep jackd" or something like that to get this information.




>
>>
>>> I don't anything perfect about jack_lsp popping up a GUI dialog to
>>> configure a server. I don't see anything good about a careful constructed
>>> GUI application having to deal with the reality of a new dialog being
>>> created. this isn't even close to perfect.
>>>
>>>
>> But it's better than having different GUIs in every client for
>> configuring jack.
>>
>
> I am fairly confident that what is better for most users is having a well
> known point of control (e.g. cadence, qjackctl) to start and control JACK,
>

And that's what I'm suggesting. One well known point of control, provided
by libjack, which every
client can use, if they want.



 as well as the capability to start the server from scripts etc.
>

Sure, there's nothing wrong creating a dummy-client that only runs the
server, if you need that.



>
>
>>
>>
>>
>>> what problem are you actually concerned with fixing? what users does it
>>> affect? when?
>>>
>>
>> I think I have listed the problems. The far worst problem is that there
>> is no proper error response when a driver doesn't start. Especially on
>> Windows,
>> where qjackctl is quite buggy and portaudio often refuses to start.
>>
>
> Qjackctl arranges to catch all output from the server, which is by far the
> simplest way to present information to the user, especially in a context
> where the reasons for failure can be incredibly complex. It might not work
> as well on Windows as it does on *nix platforms, but I hardly think that
> this would justify some new mechanism to pass failure information between
> processes.
>
>
This is so flaky and uncertain. Layers upon layers of software, which all
may fail.
The end result is that there is a higher chance for the user to not get the
information
he needs, plus the added complexity and frustration. libjack should take
care of all this.

1454315998.19842_0.ltw:2, <CAC6niELjmwbQdoZ-md21Yx2BOVWcDA7gMha3oYQmm7pPzSsG6Q at mail dot gmail dot com>