[Jack-Devel] stepping down

[Kjetil Matheussen]

On Sun, Jan 31, 2016 at 9:59 PM, Paul Davis <paul at linuxaudiosystems.com>
wrote:

>
>
> On Sun, Jan 31, 2016 at 3:48 PM, Kjetil Matheussen <
> k.s.matheussen at gmail.com> wrote:
>
>>
>>
>> On Sun, Jan 31, 2016 at 2:44 PM, Paul Davis <paul at linuxaudiosystems.com>
>> wrote:
>>
>>>
>>>
>>> On Sun, Jan 31, 2016 at 6:33 AM, Kjetil Matheussen <
>>> k.s.matheussen at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20160131/e65b66e7/attachment.html>