Summer Coding 2010 proposal - Fedora Musicians' Guide

This Is a Draft
This is simply a draft of the proposal. It contains many vague/omitted/poorly-formatted sections.

About my Project

• Name: Fedora Musicians' Guide
• Idea Page: Summer Coding 2010 ideas - Fedora Musicians' Guide
• Proposed Language: English

Description

The goal of this project is to create a User Guide for music and audio programs on Fedora Linux. The Guide will address problems and questions faced by musicians who use computers as a creative platform, in an attempt to illustrate that the specialized applications they require are available on Linux. This give the Guide a specific target audience: professionally-trained (though not necessarily practising) musicians, who have little or no knowledge of Linux, but who are capable of similar work with commercial software programs on either Windows or Mac OS X. This requires a very specific mode of writing, where I will be fully explaining the technological implications, but leaving out much of the musical implications. I do not believe that this renders the Guide inaccessible to laypeople. A concerted effort will be made to ensure that every task has an obvious outcome, so that any sufficiently creative and interested user will be able to use the Guide. Even so, the primary purpose of this Guide will be to open possibilities of open-source software to users who require specialized audio or music software.

But what format will the document be?!

Note to Self:

• 10 - 20 sentences only
• What are you making?
• For whom are you making it, and why do they need it?
• What technologies will you be using?

About Me

Contact Information

• Name: Christopher Antila
• Email Address: crantila from GMail
• Wiki and IRC Username: crantila
• Primary Language: English
• Location: Ontario, Canada
• Working Hours: about 17:00 to 2:00 UTC, but flexible

Why I Want to Work in the Open-Source Community

My previous open-source contributions are limited to bug reports for Fedora, Gentoo, and KDE. I have contemplated larger contributions in the past, but the immense time commitment is forbidding for students during an academic term. When I've been on summer "holidays," my time has been similarly consumed by a paying job, and the work required to maintain musical skills. I did not want to get involved in something that would later be left unfinished. Fedora Summer Coding will allow me to set aside the time that I would otherwise spend at a paying job.

The motivation to contribute to the open-source community stems from my belief that its values are essential to the well-being of human societies. The Fedora Project is becoming increasingly adept at marketing this philosophy, and the Four Fs summarize that point. The "freedom" and "friends" Fs are especially important to me: when you have something, you should be able to do whatever you want with it; and advancements made by one entity should be actively shared with others. This is how complex systems work: small contributions combine to make something quite unlike the parts. It would be impossible without sharing resources. Even proprietary advancements build on the readily-available work of others!

My particular project proposal, the Fedora Musicians' Guide, combines my musical abilities with my linguistic and technological abilities. Musicians are used to paying large sums of money for proprietary software that is extremely complex. Their creative work can be limited because they lack sufficient time to learn how to use their tools effectively. Although the initial learning curve can be steeper, there exist open-source tools to equal anything in the closed-source realm. My goal with this guide is to help friends and colleagues overcome that learning curve. They will save money, and be able to freely share their work. Even if they do not choose to switch to Fedora, this guide will inspire the use of open-source music tools for their chosen platform.

Also see my wiki profile page, available here.

Schedule and Task-List

Various Tasks and Deadlines:

• Featured software applications must be selected.
• Supplementary tasks must be selected.
• Suggest possible tasks and tutorial topics (i.e. chapter topics)
• Revise schedule to include specific topics for specific weeks.
• 19 May : Application must be finalized, with all above tasks completed.
• 28 May : Informed yes/no about project.

Definitions (because I don't know the 'real' words):

• Tutorial algorithm: The steps to be followed in each tutorial, such as:
  1. Open Terminal.
  2. Type sudo yum update
  3. When it stops, type y
  4. Wait for updating.
• Target-audience testing: Testing to ensure that members of the document's target audience group will be able to use the document as intended.

Schedule, by Project Week Number:

1. (28 - 30 May):
   • Ensure completion of pre-approval tasks.
   • Write message and find subjects for target-audience testing.
   • Write message and find subjects for tutorial-algorithm testing.
2. (31 May - 6 June):
   • Finalize tasks/tutorial topics.
   • Revise schedule as needed to incorporate the finalized tutorial topics.
   • Begin writing tutorial algorithms.
3. (7 - 13 June):
   • Test previous week's tutorial algorithms.
   • Finish writing tutorial algorithms.
4. (14 - 20 June):
   • Test previous week's tutorial algorithms.
   • Review algorithms, seeking possible mistakes or pitfalls, and forewarn about them.
5. (21 - 27 June):
   • Begin writing documents on the Fedora Wiki.
   • Ensure contact is made with the Docs SIG about the evolution to an "official" document.
6. (28 June - 4 July): Week of Canada Day
   • Finish writing documents on the Fedora Wiki.
   • Begin target-audience testing.
7. (5 - 11 July): Midterm
   • Continue target-audience testing.
   • Revise documents to incorporate target-audience comments.
   • Must have found editor, if the Guide is to be turned into an "official" document.
   • Write midterm report, due on 12 July.
8. (12 - 18 July):
   • Finish target-audience testing.
   • Finish revising documents to incorporate comments of target-audience tests.
9. (19 - 25 July):
   • Convert document to DocBook XML?
10. (26 July - 1 August):
    • Finish converting to DocBook XML?
11. (2 - 8 August): Week of Another Long Weekend:
    • This is a buffer week, which shall receive no assigned task.
12. (9 August): Project Completion.
    • Write final report, due 16 August.
    • Create "snapshot" of all documents, due 16 August.
    • Write evaluation, due 16 August.
13. Return to real life.

Proposed Applications

Should I combine "Recording" and "Sequencers," leaving out Qtractor? I'm concerned about getting myself into too much.

Recording

• Audacity, because it's well-known, relatively simple, and doesn't 'require' advanced configuration
• Ardour, because it's similar to a well-known commercial DAW, and should be used with advanced configuration

Sound Servers

• ALSA, because you can't escape it
• PulseAudio, because you can't escape it (in Fedora)
• JACK, because you can't escape it (if you're using audiophile software)
• Phonon, because KDE users wonder about it

These will be covered in varying detail, as required. ALSA and Phonon will probably just receive a "talking about," and not much else.

Synthesizers

• SuperCollider, because it's text-based, it gives a reason to introduce Planet CCRMA, it's full of features but relatively simple, and I know it better than Csound
• FluidSynth with QSynth, because it's graphical, works with JACK and other programs, and Rosegarden more or less needs it

Sequencers

• Rosegarden, because it's very popular, and every time I think I know what it does, I find out that it's for something else
• something else? Qtractor, perhaps?

Typesetting

• LilyPond, because it's the gold standard for typesetting in Linux
• Frescobaldi, because it increases productivity with LilyPond by quite a lot

Training

• GNU Solfege, because it's the only FOSS program of its kind (I think?)

What Testing May Need to Be Done

• test on i686, x64, and PowerPC G4(??? this would be PlanetCCRMA-less)
• test in KDE, GNOME, and XFCE
• test in VirtualBox virtual machines?
• test with single and multiple sound cards
• test with USB and FireWire sound cards
• test efficacy with "computer experts" and "non-experts"

Currently, I'm thinking that testing with equipment and architectures and equipment should be tested during the writing process, so that equipment-specific information can be incorporated to the text. Testing with various user-groups would be done subsequent to this.

Comments

Add comment

Please see the discussion page for comments.