On Wed, 4 Nov 2015, Fons Adriaensen wrote: I think the reference was to qjackctl and not jack itself. The GUI can only run one instance of jack anyway (and one instance of itself). Running two jacks generally means at least one from CLI which is where server naming makes sense. Also, more than one jack, although useful where needed, is generally not for casual/first time use. It takes some understanding beyond point and click. -- Len Ovens www.ovenwerks.net

On Wed, Nov 4, 2015 at 4:09 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote: This has absolutely nothing to do with Ardour or Qjackctl. The "named server" option requires that an environment variable be set in the environment of every client that wants to use a server started with this option. While this may be a cute hack for people who want to do things like running two jack servers on a single machine, it has been NOTHING but a source of utter confusion for almost all users, since there is no indication that its use requires an environment variable. Running two servers on one machine might be interesting for 1% or less of JACK users, but catering it to it in any significant way is just another reason why JACK continues to sit around unused by many people who could otherwise have really benefitted from it. Anyway, qjackctl's most recent version no longer exposes the option in the basic options tab, which will hopefully cut down on the number of users who mistakenly think that this option is some handy feature related to presets or something. No, its related to the presence of multiple backends. Build Ardour with ONLY the JACK backend, and ensure that JACK is already running, and you'll basically never see the dialog. But build it with more than one backend, and the user needs ways to choose the backend, at which point, things start to get much more complex than they otherwise would be.

And while we are talking about user friendlyness or confision: For those who like to stick with already available packages instead of building their own, which I guess are more than 1%, a simple option to the ardour binary or an environment variable to only use jack and don't ask for the backend at all would not hurt either. Or check if jack is already running and if then do not ask. But then again, having a _possibility_ to start ardour with a default template and not asking anything would be really a big step up.

On Thu, Nov 5, 2015 at 2:46 PM, Fons Adriaensen <fons(a)linuxaudio.org> 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. except that there is no reason to even expose this option that exists only for tinkerers and corner cases. once again, you do not sit on IRC all day answering questions about using this software. if you did, you would see the kind of havoc that this way of thinking causes when your user base looks different than a group of smart, tinkering geeks. the option does exist, almost entirely to support unusual corner cases and unusual users. there is zero reason to expose it in any software aimed at people who simply want to get things done.

On Thu, Nov 5, 2015 at 3:35 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote: 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). i want to support corner case use cases only to the extent that they do not pollute/confuse the workflow for the common case. 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.

On 11/07/2015 11:49 AM, Fons Adriaensen wrote: Then every jack app would need to implement this. More replicated code with more potential bugs. IMHO a cleaner solution would be to remove the option from jack_client_open() and always force the use of the env variable and let libjack deal with it. If a client really needs to set the server-name it can use setenv() before calling jack_client_open(). Anyway, it's too late now to change the semantics of the API. You don't know newbies: "Oh, a 'Name' field, nice I'll name my server before reading any documentation." And no, telling a casual musician to read the jack documentation first is not the way to go, either. Old qjackctl was partly responsible. The server-name field was very prominent top-middle of the settings dialog and also the only centered item which made it stick out visually. This has meanwhile been addressed (not removed, but simply moved to an "advanced" pane). Did someone suggest to remove features or make things impossible? I was under the impression that this is about clarifying and simplifying issues that are too complex or confusing for their own good. 2c, robin