Malte Steiner wrote: Ah yes, for live concerts it will be very easy... But I'm also posting this message on this list cause I'm a bit scared that there are a lot of other apps and features in the world of linuxaudio which are only known by the 'hardcore' linux audio user.... Again we're not all ict students ;) Please make clear documentation and let your mother read it first before you put it on your website.. If she understands it.. we'll understand it ;) And if not you have a very ict talented mother, or 'we' are more 'noob' then we thought we where :) (just kidding...) And we especially like clear screenshots and pictures!!! Thanks in advantage ;) ~d

And remember, anyone is welcome to contribute in documentation ;) For the "ICT" people it's "show me the code", and for the rest it's "show me the money" or "show me the words"...errr..and some other things...among others. The thing is, most of those who come to Free Software from a commercial environment have difficulty adapting to the culture. The lack of documentation is exactly the result of that fact (not being aware that you can contribute in many ways and the community thing isn't a joke at all).

david wrote: It seems to me that when you build an nice app, you'd like people to start using it... I think it's also the honourable task for a programmer to make a good documentation or to search for people who want to do it for him... Dirk

On 16/04/2008, david <gnome(a)hawaii.rr.com> wrote: So at the end of the day, do you want better code or better documentation? I would, personally, go with the former. In most cases, the documentation _is_ there - except it's too obvious and it gets missed; man pages. QJackCtl's patchbay saving feature has been around for quite some time, and a lot of guides had it demonstrated in a practical manner - albeit not really explaining it's existence.

schoappied wrote: Hmmm, actually, david gnome in hawaii did not write anything above. The joys of attribution as material is clipped. ;-) I do happen to agree that better code is better than better documentation ... but as someone who spent 20 years writing software documentation, I can tell you that 90% of the man pages I've read are worthless unless you already know the program they "document". (And, IMHO, they're really intended for command-line programs, not GUI ones.) They're really intended as a slightly-more informative way of listing and explaining a command-line program's parameters, not really showing or explaining how to use it. Sometime when I'm in a position where I don't have to spend so much time making money, I hope to do some documentation work for Linux programs. At least the ones I know and use. -- David gnome(a)hawaii.rr.com authenticity, honesty, community

On Wed, 16 Apr 2008 11:00:45 +0200 schoappied <schoappied(a)gmail.com> wrote: http://ardour.org/files/manual/sn-bcf2000.html Granted, that's using connections under the MIDI tab, but it works just the same as the Audio patchbay connections. -- ====================================================================== Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com Without deviation from the norm, "progress" is not possible. - FZappa

On Wed, 16 Apr 2008 13:53:09 +0200 schoappied <schoappied(a)gmail.com> wrote: Thanks. Honestly, I've found Qjackctl's patchbay amazingly intuitive. It wasn't hard to find, either - when I started working with the program, I clicked on all of the buttons in the main window just to see what they could do. There's a lot of information on using various control surfaces at http://ardour.org/files/manual/ch-control-surfaces.html The link I sent on the BCF2000 was an example I knew of because I wrote it, and it's BCF2000 specific because that's what I have. I think Ardour's a great example of a project that has had a group of people, a number of which are not programmers, create documentation. I think any sufficiently complex program will have a user community spring up around it that's willing to add to the collective work. Something as straightforward and intuitive as Qjackctl, not so much. -- ====================================================================== Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com Without deviation from the norm, "progress" is not possible. - FZappa

Hi, On Wed, 16 Apr 2008 00:21:12 +0300 Arda Eden <ardaeden(a)gmail.com> wrote: See http://www.rncbc.org/drupal/node/76 Greetings, Frank

M-.-n wrote: This are real good examples of how it can be. Put some discipline in the project to state that a release is only with good documentation... and otherwise hold it back for a while. And I think there are always a couple of people who really finds your app useful and it must be possible to write a good documentation with the help of them. In my experience there are a lot of people who likes to contribute (by helping with the documentation) to a project they like. I think the apps with a good documentation, publicity and good user experiences will make more change to survive in the world of linux audio. Haven't we human beings not come so far (technically spoken) by good cooperation? Good luck! Dirk

Hi, Thinking about linux audio and documentation... Isn't it strange that there isn't a good documentation for qjackctl (in combi with jack)? qjackctl is such a core app if you want to work with linux audio. And qjackctl/ jack is often a high 'threshold' to get started to use linux audio software... Ok, we've patchbay explained now, but what about the parameter settings, options, display, misc, connections (and the different tabs, audio/midi/alsa), messages and status? I think we can lower the threshold to start use linux audio apps if this important part is better explained in a good and clear (with pictures) documentation, which can be updated when there is a new qjackctl with new features. I also like to know more about it myself! Kind regards, Dirk

On Thu, 17 Apr 2008 20:25:15 +0800 "Ray Rashif" <schivmeister(a)gmail.com> wrote: There could be other confusing elements, the user initially doesn't necessarily know that start refers to the server, not the transport, if he even knows that there is a transport, or a server that needs starting. It's all not hard once you know a few basics, but many new users appear to have trouble. To find working settings appears to be the most common one. I agree that having a nice qjackctl documentation would be a good thing, but where to display it? Where will it be found easily?

Isn't the following the perfect example of JACK _and_ QJackCtl documentation? http://w3.linux-magazine.com/issue/67/JACK_Audio_Server.pdf

schoappied wrote: that's just because those apps only open as jack clients when play is hit. while it's playing, take note of the actual client and port names. you can take advantage that qjackctl patchbay socket dialog helps you on this (hint: drop-down comboboxes are populated accordingly). but, point is, you'll have to write most of your patchbay rules "by hand" in a plain declarative way, most of the time. also of note is that you can have regular expressions to refer to client/port names. isn't that neat? anyway, i've told this many times before, and i say it again, - the patchbay snapshot feature is a starting point, not and end. capisce? cya -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On Fri, Apr 18, 2008 at 4:13 AM, schoappied <schoappied(a)gmail.com> wrote: I think this is because, when your app is using oss or alsa, the friendly thing to do is to stop using the sound card (since using the sound card blocks other applications that would like to use it), and it is easier to plug in your calls to the jack api in the same place as the oss or alsa api calls, than it is to change your connection/disconnection policy based on api.

Fons Adriaensen wrote: Is this a problem of the apps like audacity or of qjackctl?

Fons Adriaensen wrote: problem 1 is an old one and is due on lack of a better mapping algorithm between actual jack graph and qjackctl patchbay models: - jack graph is represented by connecting nodes which are the actual individual ports; - qjackctl patchbay is represented by nodes (sockets), which aggregates an ordered set of ports (plugs), intentionally connectible in turn, when actively available. yeah yeah, my eloquence and/or documentation skills are even worse than my own twisted mind, the one that made this patchbay thingie from the first place :o) the other two problems (2+3) are somewhat moot imho. yes, you'll always have to save the patchbay profile, so what? right, i know the process is open for improvement (like, for example, an evil auto-save feature?) all suggestions are welcome, even better if those are laid in a patch form :))) cya -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On Fri, April 18, 2008 00:27, Fons Adriaensen wrote: i'm sure the biggest problem here is the braindead snapshot feature which doesn't do what you really want ootb. and the keyword here is the ootb;) suppose you have this connection scenario: client_a:out_1 -> client_b:in_3 client_a:out_2 -> client_b:in_4 client_a:out_3 -> client_b:in_2 client_a:out_4 -> client_b:in_1 then the snapshot will make it like: socket_a -> socket_b client_a client_b out_1 in_1 out_2 in_2 out_3 in_3 out_4 in_4 if you activate this it won't do what you want, sure. that's why you'll have to tweak the patchbay layout a little. read on the correct patchbay would be exactly this one: socket_a1 -> socket_b2 client_a client_b out_1 in_3 out_2 in_4 socket_a2 -> socket_b2 client_a client_b out_3 in_2 out_4 in_1 you see? at least you should have to copy either said sockets, remove half of the ports(plugs) on each one and reorder the plugs in one other case. imho, the big question is not whether the patchbay model doesn't fit to all purposes, but whether the current super-naive snapshot mapping is any better than not having one :) aha. so you can't save to an existing file? now that's a bug that i wasn't aware of. afaict that doesn't happen here, as it always asks whether you want to replace the old file or not. i guess a split into the old-school "Save" and "Save As..." options is in order? yes, you're right, there is no reason at all but an old implementation one. a very old in fact (4 years?:) yeah right :o) to be 'Active' a patchbay must be materialized in a file first. i still believe this is a minor hindrance but i get the point. are you sure that's not possible already? eheh, i'm always found to quote this "don't fix what isn't broken" :)) snapshots aside, maybe the biggest miss on this current patchbay implementation is that it hasn't support for jack-midi, yet ;) thanks for the heads-up suggestions, nevertheless cyaa -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

nope. the snapshot will list *all* ports oof the client, but it probably will do it as unsorted as jack_get_ports() will hand it. that is, if client_b has an additional port named "test", the snapshot result most probably will be socket_a -> socket_b client_a client_b out_1 test out_2 in_1 out_3 in_2 out_4 in_3 in_4 ah, is it simply because there is this one developer here who suffers from some form of chronic procrastination ? :) ciao -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On Sat, Apr 19, 2008 at 06:37:21PM -0400, nescivi wrote: No don't ! The procrastination processor is probably stack based. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

On Sunday 20 April 2008 05:36:15 Fons Adriaensen wrote: LOL... ~;-) drew

On Sunday 20 April 2008 05:36:15 Fons Adriaensen wrote: But if the other feature is one that is even more tedious to program... it might work? I guess we have to make a study of the requests Rui got in the past, and how and when he fixes them. If we get a sufficient psychological overview of his procrastination habits, we will know exactly what feature to ask for ;) Keep up the good work! sincerely, Marije