Schedule Buffers, Fedora Community, and Lazy Musicians.

It’s a good thing that I planned the week-long buffer zones at the end of major would-be milestones.  In part, I did that because I know that things always take longer than they seem like they should – and they are taking longer!  There haven’t been any problems (aside from the odd software bug), so it’s probably from a lack of experience that I didn’t know exactly how much time to plan.  But that’s okay.

On a related note, a big factor in my ability to keep working (that is, the reason I haven’t run into any problems) is the tremendous support that’s been provided by everybody.  My mentors have, of course, been doing their part in answering queries promptly, but nobody knows everything.  External sources, like the SuperCollider mailing list, and especially the good people of Freenode’s #opensourcemusicians channel have been quick to volunteer advice and encouragement when needed.  It is heartening to experience the open-source culture from a contributor’s perspective, which is new to me.  The open-source way, among other things, focusses on the idea that individual users contribute only a small portion, but that it is these small portions which together build something great.  The Fedora Project, and the Docs SIG (with whom I have been working), is particularly good at encouraging everybody to do their small part.

Another factor that encourages me to keep working is that, regardless of what sort of documentation I find, the exact sort of documents that I’ve been working on still seem to be missing from most music software.  This makes a certain amount of sense.  For my target audience, however, it does not.  Musicians in university music programs are often forced to use advanced and highly-specialized computer programs.  We don’t have time to really learn how to use the programs, so instead we simply learn what we need.  If open-source software doesn’t provide a way to learn the software quickly like this, then it’s not likely to be chosen over more-familiar proprietary software.

Talking to some of my peers has encouraged them to investigate open-source solutions for tasks where they would traditionally have used proprietary software.  I think that the Musicians’ Guide’s use-case-focussed instruction will provide an easy and useful way for them to learn software.  I’ve been contemplating an “embedded glossary” kind of lay-out, where the means to accomplish a task form the core of every chapter, with musical and technical definitions and explanations included in a manner that makes it easy to skip them if you’re in a hurry.  If you have the time, you can read the technical explanations.  If you’re not a trained musicians, you can read the musical explanations, too.  In this way, the document will serve the needs of both amateurs and professionals.

With prose-form writing scheduled to begin within the week, I would appreciate any sort of feedback or suggestions that the community can provide.



  1. I’m not much of a musician myself (and what music stuff I do doesn’t interact with the computer – acoustic guitar, piano) but I pointed my cousin, who is interested in computers + music, at and hopefully she’ll take a look.

    I’d like to work through the lilypond and solfege instructions myself when they’re finished – lilypond is something I’ve been meaning to learn for years, and ear-training is something I’ve been curious about but never found a way to learn. If you give me a ping when you’ve got them finished, I’ll gladly take a weekend day and go through them and give feedback. I’m mchua on freenode (and started hanging out in #opensourcemusicians) so ping anytime if you’d like testing sooner, too!

  2. Thanks for the offer! As it happens, I’ve decided to work through LilyPond first, so it should be in a “fully-completed-draft” format within the next few days.

Comments are closed.