Hi *!
Funny to see the recent activity prompted by Paul's step-down notice. I'm a bit worried to see this flurry of fundamental design discussions about putting everything into some magical lib and whatnot. Client-server thinking is a fundamental prerequisite for keeping one's sanity when using UNIX (and Mac OS X, for that matter), and it even benefits Windows users. Client-server architecture is good. It works. Nothing against automating things, but if your user-friendly application feels it must spawn a jack server for me, it needs to do all of the following: * pop open a notice to the effect that no jack server has been found and does the user want you to do that for her/him? together with a checkbox to not ask again and a notice on how to undo the "don't ask again". * spawn a jackd server and explain to the user how it guessed what configuration to use and how to change that. also point out to the user how to see/modify jack connections with jack_lsp/jack_connect (because they will always be present on any system that has jack) and of course point to user-friendly tools such as JackPilot, qjackctl, or patchage. also tell the user how to access jackd error messages. no votes for implicit magic without being obvious about what's being done. good example of how not to do magic (no systemd bashing here, plz, it's just an example!): i use cd ripping tool "asunder" and tell it to log to /var/log/asunder.log because i suspect hardware failure of a dvdrw drive. no log ever appears. days later, i look through the system journal and see that it has incorporated the asunder log messages. either asunder logs to syslog anyways and hasn't updated its gui to reflect it (then i don't have a case here), or journald has some magic to catch any attempt to start a log in /var/log and reroutes it to the global log. if the latter, then the user-friendly way to do it is to write a stub /var/log/asunder.log that contains a note as to what has happened to the log and where the information is to be found. again: no implicitism without making it obvious what is happening for old people who still think everything is a file. i still think the best way to make jack user-friendly is to quickly educate users how to start a graphical jack config and patching tool, and then start their app. this is the free software community. unless we want to make all our hangouts on IRC, mailing lists, and forums uninhabitable, we MUST NOT DUMB DOWN OUR NEW USERS, and what's worse, annoy old and experienced ones! be friendly, yes, by all means. hide the underlying workings from users and prevent them from understanding them, never. just my few cents, Jörn -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
On 02/01/2016 12:52 PM, Jörn Nettingsmeier wrote:
> * pop open a notice to the effect that no jack server has been found and > does the user want you to do that for her/him? together with a checkbox > to not ask again and a notice on how to undo the "don't ask again". > > * spawn a jackd server and explain to the user how it guessed what > configuration to use and how to change that. also point out to the user > how to see/modify jack connections with jack_lsp/jack_connect (because > they will always be present on any system that has jack) and of course > point to user-friendly tools such as JackPilot, qjackctl, or patchage. > also tell the user how to access jackd error messages. i guess my point in a nutshell is this: if you invent some user-friendliness that shields the user from having to manually set up a key part of their workflow, you are responsible for making sure they are aware what's being done, and ideally learn how to do it/control it themselves. discoverability, discoverability, discoverability. -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
On Mon, Feb 1, 2016 at 1:09 PM, Jörn Nettingsmeier <[hidden email]> wrote:
Yes, exactly, and that's one of the points I was trying to make. Starting a jackd process in the background without the user knowing is not good. Instead - and this is my highly opinioned opinion - the client should sometimes also be the server, and all the server options and feedback, should be accessible to the client. Nothing of importance to the user should be printed to stdout or stderr, or provided via a string as command line arguments. All communication should be formally specified, both options for starting the server, and feedback from the server. The driver programmer should assume that information printed to stdout or stderr will never be read or understood. And in order for the clients to show/configure the server part of the client, libjack should provide common GUIs that all clients may use. This way, you may use Ardour, for instance, alone, but you may also start the jack server with qjackctl or jackd first if you want to. Ardour will tell you if it is functioning as the server, or not. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
In reply to this post by Jörn Nettingsmeier-5
On Mon, Feb 01, 2016 at 12:52:47PM +0100, Jörn Nettingsmeier wrote:
> i still think the best way to make jack user-friendly is to quickly > educate users how to start a graphical jack config and patching tool, > and then start their app. this is the free software community. unless we > want to make all our hangouts on IRC, mailing lists, and forums > uninhabitable, we MUST NOT DUMB DOWN OUR NEW USERS, and what's worse, > annoy old and experienced ones! > be friendly, yes, by all means. hide the underlying workings from users > and prevent them from understanding them, never. Agree 100%. One person's "user friendly" is often the opposite for the more experienced user. I think the tendency to remove the need for understanding is quite unhealthy (see Darwin). John _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
In reply to this post by Kjetil Matheussen-2
On 02/01/2016 01:28 PM, Kjetil Matheussen wrote:
> Instead - and > this is my highly > opinioned opinion - the client should sometimes also be the server, i disagree, most emphatically. the client should never be the server. do you want to spend ages figuring out whether a jack problem happened with an in-process server or external server, each time a user cries their eyes out on IRC? do you want to battle all the conceptual misunderstandings about how in-process servers are faster, and out-of-process servers are more robust, and sound warmer? why? what's so bad about a clean conceptual separation? > and > all the server > options and feedback, should be accessible to the client. now that is something we can agree on, but that's *completely* orthogonal. but the way i do it, i open qjackctl and look at the message window. problem solved. and i guess i can explain that to users far more quickly than you can implement a new message passing API for jackd. developer time saved, user understanding improved. two sacred pillars of the open source culture. -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
On Mon, Feb 1, 2016 at 1:39 PM, Jörn Nettingsmeier <[hidden email]> wrote: On 02/01/2016 01:28 PM, Kjetil Matheussen wrote: Two reasons: 1. No need to use anything other than Jack. Ardour now has got the option of not using Jack. Shouldn't have been necessary. 2. It feels like a server configuration protocol will stabilize faster if clients also can function as servers since more code is using it, not just qjackctl. and It works, but the more components you glue together, the higher the chance is for something to fail. For instance didn't the messages window in the windows version of qjackctl show anything coming from jackd until autumn 2015. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
On Mon, Feb 1, 2016 at 7:54 AM, Kjetil Matheussen <[hidden email]> wrote:
if you believe this, then clearly you do not understand why we did this.
the server configuration protocol has existed for nearly 8 years. almost nobody has chosen to use it, for anything at all. jackdbus is more or less its only use case.
that has to do with windows and qjackctl, not with jackd. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
On Mon, Feb 1, 2016 at 3:02 PM, Paul Davis <[hidden email]> wrote: But it illustrates how flaky the system is when a bug like this can exist for 10 years.
I was thinking of a new configuration protocol where any libjack client can function as server.
_______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
On 02/01/2016 08:31 AM, Kjetil Matheussen wrote: > > I was thinking of a new configuration protocol where any libjack client > can function as server. > :| why would you do that? David Nielson _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
On Mon, Feb 1, 2016 at 3:45 PM, David Nielson <[hidden email]> wrote:
Well, one reason is to force forward a formally defined configuration protocol which is actually used. qjackctl would be forced to use this configuration, and the same with jackd. No more flaky use of sending around very informally specified strings via stdout and stdin as a communication protocol. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
In reply to this post by Kjetil Matheussen-2
On 1 February 2016 at 22:31, Kjetil Matheussen <[hidden email]> wrote:
>>> to fail. For instance didn't the messages window in the windows version >>> of qjackctl show anything >>> coming from jackd until autumn 2015. >> >> that has to do with windows and qjackctl, not with jackd. > > But it illustrates how flaky the system is when a bug like this can exist > for 10 years. No, a 10 year old bug illustrates nothing but the nature of open source. For a bug to be fixed it must (a) be encountered (b) be reported and (c) receive developer attention. (a) & (b) is extremely hard for qjackctl on win32 because the majority of the userbase is on a different platform. Hats off to yourself for stepping up to fill (c) and giving win32 some much needed attention, but this doesn't make jackd "flaky". Your proposal doesn't make sense in general. It's narrow minded and very focused on the GUI application use-case. Most of the JACK clients I run have no GUI at all. If they are the first client to run and you still want to configure JACK's options via a GUI, you *need* to spawn a separate process. Anyway, a separate process makes the whole system *more* robust, not more flaky. If the jack server is running in the same address space as a client, then an error in that client (segfault/buffer overflow/etc) can bring down the entire audio system. It sounds like the existing configuration mechanism provided by jackd enables you to do what you want already (ie. running ~/.jackdrc). You can do literally whatever you want in this script. You don't have to run jackd directly, you can write a GUI frontend that lets you configure options before launching jackd and make ~/.jackdrc launch *that*. The best part about this is that it just works with no change to jackd, no change to libjack, and no change to any clients. This is UNIX philosophy. We have simple tools and we glue them together. And the result is beautiful. Well, sometimes :) While I'm here let me throw in a thanks for jack. It's a beacon of simplicity in the mess that is linux audio. If it wasn't for bluetooth I would still be using it exclusively rather than being stuck with pulseaudio :) -sqweek _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
In reply to this post by Kjetil Matheussen-2
On Mon, February 1, 2016 15:49, Kjetil Matheussen wrote:
> On Mon, Feb 1, 2016 at 3:45 PM, David Nielson <[hidden email]> > wrote: > >> >> On 02/01/2016 08:31 AM, Kjetil Matheussen wrote: >> >>> >>> I was thinking of a new configuration protocol where any libjack >>> client can function as server. >>> >> >> :| >> >> >> why would you do that? >> >> Well, one reason is to force forward a formally defined configuration >> > protocol which is actually used. qjackctl would be forced to use this > configuration, and the same with jackd. No more flaky use of sending around > very informally specified strings via stdout and stdin as a communication > protocol. with all respect, the client/server model of jack seems well designed. we could argue about the use of clients autostarting the server (with semi-default and semi-custom settings in any jackdrc file), since if the server doesn't run, nobody has started it explicitely thus the clients can't work. if there are multiple choices of audio device to use, that is HDMI, intel analog, external attached USB, firewire .. i think the autostart feature is one of the pitfalls that made users see many of the "could not start" messages. plus that there is some problems with multiple sound servers wanting exclusive access to the device. other issues are not mainly jack's problem, which is configuration of the system (permit RT to to user, possibly use lowlateny kernel) and badly programmed clients that behave one way or the other and can affect the server operation as a whole. which again is a side-effect of this open ecosystem. if i run a system with just jack, alsa, ffado and known-to-work clients installed it works better than anything else. building the gui into the server is surely not a good idea. a recent "stock" install of a selection of jack tools showed no major issues. it's a really mature ecosystem. if it doesn't change all the time, this can be a sign of "close to finished" that again is what makes lasting APIs useful. look at VST or any out-dated standards. one aspect these plugins are still in use is that the API didn't change much. compare it with PI, it didn't change much, is used in many formulas and saying PI is dead is as funny as saying JACK is dead :) greetings tom _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
In reply to this post by sqweek
On Mon, Feb 1, 2016 at 4:39 PM, sqweek <[hidden email]> wrote: On 1 February 2016 at 22:31, Kjetil Matheussen <[hidden email]> wrote: I understand why things are like they are. I'm not claiming anyone has done a bad job. Absolutely not. I just point out that things can be better. Had there been a libjackserver library, where the server itself had been included, qjackctl could have linked to that library instead of starting a process and do very informal and flaky communication between the server and the GUI. (Oh, and regarding the qjackctl bug. I didn't only do (c), I also fixed the bug itself) Your proposal doesn't make sense in general. It's narrow minded and No, it's not. I'm proposing to put the jack server into a library, preferably libjack. jackd wouldn't stop to exist because of that.
But I'm not proposing to remove jackd. If you want to continue using jackd, you can. It sounds like the existing configuration mechanism provided by jackd That's all good. But as I've pointed out, there's no proper way to find out what's really happening. libjack should have a 'char *jack_info()' function that clients can display, as a minimum. The best part about this is that it just works with no change to And I'm proposing to extend that thought further by putting the server part of jackd into a library. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
In reply to this post by Thomas Brand
On 02/01/2016 04:43 PM, [hidden email] wrote:
> compare it with PI, it didn't change much, is used in many formulas and > saying PI is dead is as funny as saying JACK is dead :) > greetings > tom well, there is pi v2: https://en.wikipedia.org/wiki/Turn_%28geometry%29#Tau_proposal (sorry, couldn't resist) -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
On Mon, February 1, 2016 16:53, Jörn Nettingsmeier wrote:
> On 02/01/2016 04:43 PM, [hidden email] wrote: > > >> compare it with PI, it didn't change much, is used in many formulas and >> saying PI is dead is as funny as saying JACK is dead :) greetings tom > > well, there is pi v2: > https://en.wikipedia.org/wiki/Turn_%28geometry%29#Tau_proposal > > > (sorry, couldn't resist) > > this is just a question of mapping (/me thinks "..-compat" ;) _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
In reply to this post by Kjetil Matheussen-2
On Mon, Feb 1, 2016 at 9:31 AM, Kjetil Matheussen <[hidden email]> wrote:
This already exists. I am a little shocked that you don't know this.
No, it does not. It illustrates how shallow and low energy the development "team" for JACK is, especially on Windows. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
In reply to this post by Kjetil Matheussen-2
Le 1 févr. 2016 à 16:53, Kjetil Matheussen <[hidden email]> a écrit : > > > On Mon, Feb 1, 2016 at 4:39 PM, sqweek <[hidden email]> wrote: > On 1 February 2016 at 22:31, Kjetil Matheussen <[hidden email]> wrote: > > > > The best part about this is that it just works with no change to > jackd, no change to libjack, and no change to any clients. This is > UNIX philosophy. We have simple tools and we glue them together. And > the result is beautiful. > > And I'm proposing to extend that thought further by putting the server part > of jackd into a library. GRRR : libjackserver has been there since 2007 ? 2008 ? and jackd is (since that time….) an executable that uses the so-control API to start and control the server, and is *linked* with libjackserver… Stéphane _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
On Mon, Feb 1, 2016 at 11:07 AM, Stéphane Letz <[hidden email]> wrote:
I think that this deserves more than just a "GRRRR" Stephane :) _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
In reply to this post by Stéphane Letz
On Mon, Feb 1, 2016 at 5:07 PM, Stéphane Letz <[hidden email]> wrote:
Oh, right. That's what I thought too, but I must have misunderstood what Paul meant by "libjackserver isn't what you think it is". Anyway, good to know. Now we only need to add gui functions to libjackserver (i.e. pull out stuff from qjackctl into a new executable which can only be started by libjackserver, and communicate with that executable via sockets), move libjackserver into libjack, and let jack_client_open start jack via libjackserver. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
On Mon, Feb 1, 2016 at 11:23 AM, Kjetil Matheussen <[hidden email]> wrote:
GUI functions? they'd have to be in a separate process. so you still have to write a different executable, which means you're basically reinventing qjackctl but just fork+exec'ing it from a client rather than using jack auto-start features, plus making the real client wait until the server appears (which could be seconds, minutes or hours later). _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Free forum by Nabble | Edit this page |