31 Jan
2016
31 Jan
'16
8:11 a.m.
On Sun, Jan 31, 2016 at 8:37 AM, Christian Schoenebeck <
schoenebeck(a)crudebyte.com> wrote:
On Sunday 31 January 2016 14:44:42 Paul Davis wrote:
parameters
i don't think that this isn't accurate.
(1) JACK *has* to know what the data is because it has to (potentially) mix
it. this has always been true.
(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.
> 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 as it did last time. this has worked for years.
no?
Well, it worked for many, but it also had confusing aspects for many
users, on
Linux at least.
Anyway, IMO many proposed useful features never made into JACK due to
generalization concerns. JACK's general design concept was always "it's
just a
server with a set of buffers being passed around, JACK does not know or
care
what the content of the buffers is". And this fundamental design barrier
was
defended over years, which caused it to age.
Generalization of software is good for developers, but real value for
users is
added by adding customizations for the main purpose it is used for. And the
main purpose of JACK is distributing audio signals with audio applications
and
audio devices, not distributing RSS feeds between coffee machines.
Accordingly
important features for that purpose, like the ability to control the gain
factor of audio connections should IMO be incorporated directly into JACK.
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).
Another internal deficit was the policy how to deal with laggy clients.
Which
is quite important for consumer use cases. Instead of simply kicking out a
laggy client from the signal graph it would be better to handle it like
CoreAudio does: that is automatically increasing the latency instead.
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.