[LAU] Ardour4 and named jack?

Paul Davis paul at linuxaudiosystems.com
Thu Nov 5 21:09:43 UTC 2015

On Thu, Nov 5, 2015 at 3:35 PM, Fons Adriaensen <fons at linuxaudio.org> wrote:

> On Thu, Nov 05, 2015 at 03:02:06PM -0500, Paul Davis wrote:
> > almost no JACK clients that i have ever read the code for support
> > explicitly naming the server. thus, for the overwhelming majority of
> users,
> > this remains the effective reality:
> >
> >    If unspecified, use "default" unless $JACK_DEFAULT_SERVER is defined
> in
> > the process environment.
> The clean solution to that would be to remove testing that
> env variable. In other words, *if* you want a non-default
> server, you (the app) has to specify it. Much less confusing.

this doesn't address what happens when someone has started the *server*
with a name (because they didn't understand the significance of doing so).

> > > And any dialog used to configure an
> > > app's  audio interface can have a field offering the same
> > > choice (with 'default' or an empty string as the default).
> > >
> >
> > except that there is no reason to even expose this option that exists
> only
> > for tinkerers and corner cases.
> I take note of the fact that you don't want to support
> some of my use cases, even if that would be very simple
> to do, just because of this opinion that minorities can
> or should be ignored.

i want to support corner case use cases only to the extent that they do not
pollute/confuse the workflow for the common case.

> > once again, you do not sit on IRC all day answering questions about using
> > this software.
> If that is your problem then *just stop hanging out on IRC all day*.
> Honestly, I can't imagine how anyone can do any sort of serious work
> requiring a minimum of concentration, or enjoy any entertainment, or
> whatever, if he/she his hanging out on IRC all day. It's your choice.

i write software for other people, not for myself. ssupporting them through
IRC is time-efficient even if it is not always attention-efficient. i also
write software in active collaborations with several other developers, who
do not all share the same geographic space.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20151105/cbad6323/attachment.html>

More information about the Linux-audio-user mailing list