<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 31, 2016 at 8:37 AM, Christian Schoenebeck <span dir="ltr"><<a href="mailto:schoenebeck@crudebyte.com" target="_blank">schoenebeck@crudebyte.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sunday 31 January 2016 14:44:42 Paul Davis wrote:<br>
> > I don't think Jack is the wrong solution for a DAW either. But Jack never<br>
> > got finished.<br>
> > It has a wonderful API, but it shouldn't be a struggle for a program to<br>
> > create a jack client<br>
> > if a jack server isn't running. (there were a lot of talk about this<br>
> > around 10 years ago,<br>
> > but the end result never became as good as it should I think).<br>
><br>
> i am not sure what the problem is here. if the client doesn't specify<br>
> anything, then the server will start automatically with the same parameters<br>
> as it did last time. this has worked for years. no?<br>
<br>
</span>Well, it worked for many, but it also had confusing aspects for many users, on<br>
Linux at least.<br>
<br>
Anyway, IMO many proposed useful features never made into JACK due to<br>
generalization concerns. JACK's general design concept was always "it's just a<br>
server with a set of buffers being passed around, JACK does not know or care<br>
what the content of the buffers is". And this fundamental design barrier was<br>
defended over years, which caused it to age.<br></blockquote><div><br></div><div>i don't think that this isn't accurate. <br><br></div><div>(1) JACK *has* to know what the data is because it has to (potentially) mix it. this has always been true.<br></div><div>(2) adding new data types to JACK is a relatively simple matter from the perspective of jackd and libjack. It isn't simple for applications/clients, which have to deal with the possibility of ports of "odd" types.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Generalization of software is good for developers, but real value for users is<br>
added by adding customizations for the main purpose it is used for. And the<br>
main purpose of JACK is distributing audio signals with audio applications and<br>
audio devices, not distributing RSS feeds between coffee machines. Accordingly<br>
important features for that purpose, like the ability to control the gain<br>
factor of audio connections should IMO be incorporated directly into JACK.<br></blockquote><div><br></div><div>this is VASTLY less important than global latency management. almost every client that writes data to a JACK port has a gain control somewhere in the path that leads to the port, and manages gain for its own reasons. but very few clients (if any) can truly manage latency issues, and i have reversed my original position on this (which used to be that clients should do it). <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another internal deficit was the policy how to deal with laggy clients. Which<br>
is quite important for consumer use cases. Instead of simply kicking out a<br>
laggy client from the signal graph it would be better to handle it like<br>
CoreAudio does: that is automatically increasing the latency instead.<br></blockquote><div><br></div><div>given that jack2 (the most widely used implementation) still doesn't have automatic/builtin MIDI bridging, as well as no easy way to use multiple devices, i think that's a much less important issue (particularly since jack2 doesn't kick clients out under almost any circumstances at all. <br></div><br></div></div></div>