Summer Coding Final Report for Musicians’ Guide

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.

Advertisements

4 Comments

  1. One task that I have found all of the various notation editors to be equally horrible at performing is transcription. Here’s what I’d like to be able to do:

    Hear a sequence of notes.
    Write down each of the tones as a whole note.
    Go back and adjust the duration of each note and insert rests
    Have the editor calculate the bars/measure locations

    Does anything do this? I’d rather not write in a format like ABC or Lilypond. Which of the editors that you have worked with do you think is closest to supporting this style of input?

  2. Thanks for the link, Till… I’ll add it into the post.

    As for your question, Adam, my preferred editor for transcription is “pencil and paper.” This has a lot to do with how I transcribe, and particularly how I notate pitch. But that’s another story entirely…

    For adding pitches first, and rhythms later, I would recommend LilyPond. It allows you to write the pitches first as whole notes:
    c1 d e f g a b c
    and the rhythms later:
    c4 d e8 f16 g a2 b4 c

    Since you’d rather avoid LilyPond, my “next-best” recommendation is Rosegarden. The features discussed in section 9.4.3 of the Musicians’ Guide might help you out. That said, I wouldn’t personally use Rosegarden for notation of anything. Your experiences with it may be different, but I have a hard time working with Rosegarden’s notation editor.

    I have not tried Denemo, MuseScore, or any other Linux notation program that is not in the Musicians’ Guide.

    If you find a good solution, Adam, please let me know, so it can be posted on the Fedora wiki. Thanks!

  3. I tend to do the pen and paper thing my self.

    One problem with ABC and LilyPond is they make me think in symbols, not in music. If I am thinking in pitches, I don’t want the “ABC” part of my brain engaged.

    I’d love to get the computer to play the pitch in MIDI as I enter it, so I know I have the right pitch. I know that closed source packages do this. I’m tempted to try to hack one of the open source ones, just not sure which.

Comments are closed.