Re: [Jack-Devel] stepping down

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 ...


>
>
>> 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,
as well as the capability to start the server from scripts etc.


>
>
>
>> 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.

1454278210.28326_0.ltw:2, <CAFa_cKm=kXdgV6F1+VuQHiNXGPHEX_e-evi_w2b_E2GTBm4jMw at mail dot gmail dot com>