The Fedora Musicians’ Guide is now complete (as required by Fedora Summer Coding, at least – draft is available at this link). In case you’ve missed my previous posts, here’s a brief description of the project, how it began, and how it has developed so far.
The Fedora Musicians’ Guide (or “FMG”) was designed specifically as a Fedora Summer Coding project. The idea came to me when I saw the request for student applications to Fedora Summer Coding. Because I have taken two Computer Science courses, I thought I would try to apply for something. When I looked at the existing proposals, I realized that two terms of CS just wouldn’t cut it. After thinking about what I can do, I realized that, as a university music student, I have a rather unique view of Linux. In particular, I knew that the existing documentation for music software was woefully insufficient. It still is, by the way. Thankfully, the Fedora community came together and allowed me to write a brand-new user guide for some of the most popular music and audio software available in Fedora (and some less-popular things, too).
The proposal was quite specific about the Guide’s goals. The target audience is people like my friends and me, who study (or have studied) music to a relatively high level. The document has relatively few technical musical explanations; users are expected to already know music notation before they use the LilyPond chapter, for example. Users are expected to know what they want to do, but not how to do it. In a way, I wrote the FMG specifically for my friends, because I was tired of saying “you can use this program on Linux,” knowing full well that a lack of documentation would prevent them from figuring it out.
The approach to each chapter shows the minimum skills required to use the application or program. It’s best to learn through independent experience, so I wanted to explain as little as possible, encouraging readers to learn and experiment by themselves. At the same time, I want to provide enough information that readers can guess intelligently how to do things. This was very difficult, and I was always debating with myself about how much detail to include, and how much to assume the user would already know.
It was also important for me to write something distinctly different from pre-existing documentation. Ardour and Audacity already have excellent user guides available on the internet, and SuperCollider has a very extensive collection of help files. The point of the FMG, as much as it can be, is to get users started with the software as quickly as possible, showing them how to use it with follow-along tutorials. The tutorials have instructions to create a particular, real-world project, with instructions for the tools being used, and explanations of why those tools are being used in that particular way.
The FMG currently covers the following software: Audacity, Ardour, Qtractor, Rosegarden, FluidSynth/Qsynth, SuperCollider, LilyPond, Frescobaldi, GNU Solfege. There are also chapters about audio recording, computer audio, and real-time Linux systems, for users who need them.
It’s difficult to know how well the Musicians’ Guide has met the goals I set for it. As development progressed, I found that it was much easier to write about the best software, and much more difficult to write about the merely high-quality software. I fear that this shows in the resulting document – that software like Audacity (because it’s not new to me, and it crashed often) and Rosegarden (because it’s quirky and difficult to guess) are in the greatest need of good documentation, but that I was unable to provide it.
GNU Solfege, in particular, is a project that needs help. I included it in the FMG because aural skills software is one area that computers are most useful to musicians, but it is always neglected. The real problem is not that GNU Solfege is bad software, but that it simply needs more exercises. These exercises are easy to write, too! I sincerely hope that the Musicians’ Guide helps people to discover Solfege, and encourages them to write more exercises, especially for melodic and harmonic dictation.
Looking back over the whole project, there are a few things that stand out in my mind:
* Writing documentation is a tedious task, but a very useful one.
* Some of this software is *very* difficult to use by guessing.
* Some of this software seems difficult to use, but is actually easy.
* Most of this software is very useful, comprehensive, and high quality.
The point of Fedora Summer Coding (I think… ) is to encourage new contributors to the Fedora Project. I am very grateful for the general friendliness and helpfulness of members of the Fedora community, and I feel like, even after just two months, the community has welcomed me as a valued part of the team. I cannot emphasize enough how important it is to receive encouragement from other community members. And it worked! As it stands now, I plan to remain with the Documentation Project, helping where I can.