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 :))
Post by Steve Harris Post by Richard Bown
The point is that selling Linux Audio isn't just about Linux Audio -
it's about selling the whole desktop. It's about letting people know
that if they want to make music they can just get on and make music.
People shouldn't have to have a degree to install music software and to
start using it. This problem is bigger that LAD/ALSA or even AGNULA
and it crosses that distasteful line between hobbyists twiddling and
research and big business. It treads on a lot of toes.
The problem, I think, is the state of the software that many of us are
happy to use. It needs CVS this, and pl17 that, and we stop hacking when
it builds on most peoples machines and doesn't crash too often.
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
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
If the system is worth building, build it properly, and they will come.
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.