Patrick Shirkey wrote: One of my ideas was to get a community fund for advertising in the correct publications. I know several people have reservations about running a non-profit financial system around here but most of the concerns appear to have been based on trust issues and having someone who is willing to do the grunt work. My suggestion is that we ask the people on this list who have proven their trustworthyness and live in strategic countries like England, Germany, USA, Australia to open a savings bank account which we can deposit funds into. The account would belong to the person who opened it so they would also be able to close it if it became a drain. This would allow us to easily collect funds which we could use to advertise in the correct publications on a national/regional basis. In order to find the correct pulications I would like to canvas this community for a list. Don't send in names yet. First we need to decide on what qualities we are looking for. I am willing to collate this information and write it up into an official site and document (no prob for me these days). So please don't flame me about this concept. Instead let me run with the ball for a while and see if I can gather some momentum. The more help and support I recieve from round here the better the chance is that I will keep the wind in my sails. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

On Fri, Oct 18, 2002 at 02:55:28 +0100, Richard Bown wrote: Yes. It has been my intention to pull in a few favours once I consider Linux audio to be competetive with other platforms. A friend writes for the German "Keyboards" magazine, and he has promised to cover Linux in an indepth article when its viable, and a friend-of-a-friend-of-a... writes for Sound On Sound (a respected UK publication) so I could proably get him to do something. Notice the future tense. I dont think its a good idea now, better to wait 'til we have a nice bunch of jack'd (+ alsa midi/whatever), stable, documented apps, all playing well together than put people off with the kind of stuff we're prepared to use. Something I think is important is mouse launched applications - no "app_foo -Zdr7 alsa_pcm:in_23 alsa_..." I know most of us will want to run that this way anyway (well, I will ;), but windows and mac users aren't going to be too impressed. Yes, I am guilty of this. Things like jack have to be graphically wrappered or hidden too, no scrolling text windows of xruns. The occasionaly discussed jack session saving gizmo would be a knock dead feature. That said, I think Patrick is right to start thinking about this now. - Steve

On Fri, Oct 18, 2002 at 04:49:43 +0100, Richard Bown wrote: No, I agree. You're talking to the guy who spend an evening drawing cheezy moving-needle meters in gimp ;) Maybe, but the people I'm thinking of are looking for a replacement for thier protools+logic systems, not cubase or cakewalk. Home users are important too, but... I'm not sure it ever will. I dont think theres that much overlap between protools and cubase. - Steve

mmm a jack controller app that you could configure (with a mouse) start jack and check the current state, use as a central patchbay... anyone working on such a thing? dave

Patrick Shirkey wrote: http://www.djcj.org/LAU/openads/ -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

Hi all, If you're a coder, *please* read my long rant below. It contains many project management details that I've been collecting over the past few months, and I honestly hope it can be useful to the LAD community. What if you're not a coder? there's plenty you can do to help out! We don't just need apps, we need documentation and tutorials. We need promotional crap: screenshots, audio demos (I've been going crazy with these for sweep lately, but I'd really like to hear more from what other software can do, and these are *essential* for showing the world what can be done with Linux audio). Make some recordings from your favourite apps, hook up your favourite filters, make a LAD fan site :)) ok, here we go with the well-meaning rant: On Fri, Oct 18, 2002 at 10:18:02AM +0100, Steve Harris wrote: <rant mode="ON"> ok, I totally agree with Steve here. there's a _lot_ of really good coders in this community. There's a lot of good code floating around. The only problem is making the resulting software accessible to the general public. I've been extremely lucky to learn what this means; a year ago I thought I knew, but now I look back and know I sure has hell didn't. Opportunity forced me to learn this (sweep, Pixar, yada yada yada) -- I was forced to sit back and think "shit, if this code is going to get seriously used, it had better be seriously bloody useful". I've been luckier still to have the opportunity to keep working on sweep at csiro.au, but now, even though we're doing research work with it, I'm trying to maintain the goals of it being both production quality and accessible to the general public. These are two different things, and I'm not out to diss anyone's coding abilities -- this isn't about being a good coder and being smart enough to solve tough problems -- this is about having the perseverance to spend hours tracking down stupid little bugs, it's about checking every single little error condition that could occur, it's about second guessing problems with file permissions and invalid input. In libraries and daemons, it's about giving exact error states to apps and only printing to log files. In a GUI application, it's about using info dialogs not printfs, and it's about making dialogs that (for the general public) assume no knowledge of audio (sample rates etc.) -- but still making them useful for experts. I spent the first few months of the year spiffing up sweep and getting rid of a crapload of stupid bugs. Slowly I realised my attitude changed from "I'm a leet haxor dude, ignore those crashes they're trivial" to "whoah, what a stupid bug, I'd better put some coffee on and stomp on it". I worked over the usability, and I went for a month or two spending as much time in the Gimp drawing little pixmaps as actually writing code. These last few weeks, sure I've put in support for new codecs (vorbis, mp3, speex ;) but I spent as much time making dialogs (threadsafe system error dialogs in GTK, and other fun ways to spend a lazy tuesday afternoon), checking file permissions, and catching system errors. none of this stuff is hard -- it's certainly the most mind-numbing part of writing audio software. I much prefer to spend my time tweaking filters and mixing beats. But I'll tell you what, a few weeks ago I went to a mate's place, plugged my laptop into an amp and we jammed for four or five hours, him on a keyboard, me mixing a bunch of loops and dropping samples with sweep. Sweep didn't crash once ... until 3am, when it barfed on some silly file access error as its sleepy user (me) accidentally hit save on the wrong thing. It was time to go home, and I fixed that bug the next day. Nevertheless it was really satisfying knowing that sweep could stand up to that kind of usage, and if it wasn't for the hours of mind-numbing effort I'd put into fixing bugs and testing error conditions, it simply wouldn't have been up to the task. And I'm confident that next jam, it'll last even longer :) ok, that's general coding stuff covered -- write good code, try to make sure it doesn't fall over no matter what you throw at it, make it speak to users in terms they understand. It takes just as long to write this tedious code to make your program generally useful, as it does to write the cool audio whacking functionality. Deal with it, stop kidding yourself, just sit down and write the damn code. Pace yourself, put off the next set of whizz bang features until the current set are rock solid. Now then, how to get the code out to people? Make releases. This is what Steve's talking about above, don't just leave your code sitting in CVS and expect users to sync up to it. You think your code's not good enough to release, or that doing that will raise too many expectations? bullshit. If your code is alpha quality, mark it as such, people will respect that. But, having a tarball with some kind of notion of "this snapshot is worth trying out" is far more useful than "get it out of CVS, if you're lucky not too much will be broken at that particular instant". Make those releases regularly, and make it a point of pride that at each release you've fixed as many bugs as you've added features, and that you're providing some level of assurance that the project is on track. You want to use CVS to experiment with random new features, and there's no way you can see anything release worthy in the next six months? probably bullshit. Most new features can sit in an experimental branch of the source, without a separate CVS branch -- you only need those for total rewrites. Have an "experimental" configuration option which pulls in the not-quite-ready code, but at each release make sure that the experimental branch still compiles -- sweep, libsndfile, the Linux kernel do this, and it's far easier than letting CVS branches wander off and trying to do "a big merge" (phwoar!) later. This way, people can still work on the in-development code if they want to, it's always synced to the current state of the rest of the code, and you can _still_ provide some assurance that the default build is "stable". Now, where were we .. tarballs. Right, who likes tarballs. Trick question, the answer is GEEKS. Geeks love tarballs, geeks love sourcecode. Problem is, we're trying to make software that non-geeks will use. Non-geeks are a wierd bunch, they often lack essential organs like gcc. I went through the enlightening experience of handholding a non-geek, via email, in a different timezone, through "./configure; make" on a half-installed system with a distro I wasn't used to, for a few weeks. Ideally, there will be binary packages for your program. You don't need to be the one making these, but you do need to make sure that others can build these as easily as possible, and it's a good idea to make your source autoconfigure itself as helpfully and accurately as possible. You already use automake/autoconf/libtool/etc? great. You use the supplied library macros (AM_PATH_BLAH, PKG_CONFIG_CHECK etc)? that's a good start. If they fail, do you bomb out with a few short words of error message or do you provide useful info? "but I've got that library installed and it still fails!!!" -- non-geeks often don't understand the difference between a library and it's devel package; if the macro fails, check the library, and check the header. Provide a summary of what's missing, or what configured ok. Provide URLs of where to get the missing libraries. Sounds like a lot of tedious configure.in scripting? Deal with it; it's easier than putting the same info in emails to the few users who bother to ask you, and it gets the info out to the potentially many more who will otherwise just give up silently. without meaning to pimp sweep too much, it's configure.in has grown to over 500 lines of boilerplate shell script, all out of necessity. If you can compare strings and write if statements, you can write a decent configure.in. Take mine, write your own, whatever, just stop putting it off and do it. ok, we've covered coding and configuration. Encourage others to make binary packages and maintain them (there's way too many distros for you to do the job properly). A really important thing to note here is the feedback loop between users and developers. If you want to fix bugs and get really good feature requests, you need users using your program. The best way to get real users is to have binary packages available, the next best way is to make it as braindead easy as possible to configure and build from source. Put the configure help in early, fix trivial bugs in even the earliest versions (bad input, non-existant files, etc). Close the feedback loop between users and developers as early as possible, as it grows it will strengthen your project. At every release (ideally once a week or so) try to keep the source in a "useful" state, not just "whizz bang crash". Imagine real people using your program; imagine you had to ship it off on CD to martians who can't contact you for further advice. Imagine your long-lost childhood sweetheart finding your program on the latest RedHat CD: will they be impressed, or will it blow up in their face? As Dilbert's pointy haired boss would say, "whatever it takes to motivate you, think about that". Take your program seriously, that's the _only_ difference between a real app and a "toy" -- put the attitude in place first, then the functionality will appear as if by magic. Right, as you can probably guess by now, my attitude here is very much "if you build it, they will come". You have to trust yourself on that. First, you have to throw away the geek arrogance that your code is great but everyone else must be stupid for not using it, and realise that you probably just need to fix a few little things to make it actually useful. Identify these things, write them down, stomp on them one by one. If your software is worth building, build it properly, and they will come. Now then, what's the state of Linux audio? The rest of the world is ignoring it because they're stupid? bullshit! Everywhere I go, I hear musicians and DJs saying they want to try out Linux, and they've heard good things about it. They know Linux is stable and has excellent potential for low-latency audio, they know that kickass innovative products like FinalScratch use Linux. Sure, I hear this in Sydney, which has a pretty vibrant alternative electronic music scene. The point is, people _know_ Linux rocks, they're just waiting for the apps. And they're not waiting with their fingers on the keyboard, frantically patching kernels and syncing CVS trees between gigs. They're waiting for a time when a simple CD install of ... whatever -- Mandrake, SuSe, some packaged AGNULA from their local music store ... simply boots and runs kickass apps that don't fall over, and don't spew cryptic error messages. If the system is worth building, build it properly, and they will come. </rant> I hope I haven't offended anyone with all that, I'm referring to a general attitude not any particular project. The advice I'm giving isn't perfect, and I need to do a better job of taking it myself -- there's still gaping big TODOs in sweep, --enable-experimental was broken in the last two releases, it's sorely lacking in documentation. But everything I've described has worked well for me, and I hope it does for you too. Linux audio rocks hard, and it's only getting better. Let's start taking it to the real world. Conrad.