Summer Coding 2010 proposal - Fedora Musicians' Guide

From FedoraProject

Jump to: navigation, search
Important.png
Proposal deadline is passed. This page is locked.
Do not change any details on this page. If must change something, talk with the project mentor first.

Contents

About my Project

Description

The goal of this project is to create a user guide for music and audio programs on Fedora Linux. The guide will illustrate both basic and advanced uses of leading open-source audio software, in an attempt to address problems and questions faced by musicians who use computers as a creative platform. This gives the guide a specific target audience: well-trained musicians with little or no knowledge of Linux, who are capable of similar tasks with commercial software applications on Windows or Mac OS X. These users traditionally pay large sums of money for closed-source software, so this guide will show that the specialized software applications required by these users are available and operable on Linux.

The target audience requires a specific mode of writing, where the technological implications of their actions will be fully explained, and the musical implications will be mostly absent. I do not believe that this renders the guide inaccessible to laypeople: it is always the user's responsibility to decide what to do; this guide will show them how to do it. Furthermore, a concerted effort will be made to ensure that every task has an obvious outcome, so that any sufficiently interested user will be able to benefit from using this guide.

The document will be written on the Fedora Wiki, with a probable transition to DocBook XML and Publican.

Note that my 'convincing paragraph' is here.

Benefits to the Community

Impact on the Fedora Community

How I Will Keep the Community Informed of my Progress

In addition to blogging twice a week, I intend to publish a weekly summary of my activities to select newsgroups (at least summer-coding-discuss, and perhaps also music@fedora, docs@fedora, or Planet CCRMA). Furthermore, all of my development will take place publicly on the Fedora Wiki. This will inevitably lead to some confusion, and temporarily poorly-organized wiki pages, but it has the benefits that I can carry out development from any computer, that it is an established platform for community interaction, and that anybody has the ability to monitor and contribute to the project's progress. Also, it allows the widest possible target-audience testing. A regularly-updated, detailed schedule on the wiki will help observers to track my progress.

How I Will Solve Problems if my Mentor(s) Is/Are not Available

This is obviously a difficult situation, and it is one of the reasons that I chose the development method above. Because of this, some people may already be watching; if they aren't, then it will be easy for me to show them where I'm having trouble. Another key strategy, which will hopefully help avoid becoming stuck in the first place, is to read other, similar documents, for this and other operating systems. By reading existing documentation, I hope to avoid pitfalls that may limit the usefulness of this existing documentation. Of course, IRC channels, mailing lists, and internet search engines are an obvious possibility.

About Me

Contact Information

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.

I Believe in Myself!

As a student of music history and theory, much of my livelihood involves managing large research projects. As a keen user of Linux for most of this time (and of Mac OS X for the rest of it), I have grown accustomed to using open-source tools to wholly or partly complete these projects. Furthermore, a scholarly paper and a user guide are both large documents, written with a specific purpose in mind. They both require a great deal of thought, planning, and organization on the part of the author(s). They both also require great attention to detail, and it is here where my musical training will help the most. Attention to detail is part of what makes or breaks the career of a Western classical musician. Many years of musical training - followed by four years of study at a university - have taught me quite a lot about rehearsing every possibility multiple times, just in case it fails once or twice. This unique perspective, primarily as a musician rather than a computer programmer, is the reason that I believe my abilities are well-suited to this task.

Definitions

I use the following terms in the following ways.

Schedule, by Project Week Number

  1. (28 - 30 May):
    • Write message and find subjects for tutorial-algorithm testing, and target-audience testing.
    • Create development/testing environments (list is for personal reference):
      • Fedora 13 x64 (KDE only) on fwt
      • Fedora 13 i686 (KDE only) on hp
      • Fedora 13 x64 (KDE) in vbox
      • Fedora 13 x64 (GNOME) in vbox
      • Fedora 13 x64 (XFCE) in vbox
      • Fedora 13 i686 (KDE) in vbox
      • Fedora 13 i686 (GNOME) in vbox
      • Fedora 13 i686 (XFCE) in vbox
  2. (31 May - 6 June):
    • Finalize tutorial topics, revising schedule as needed.
    • Compile list of users/platforms willing to help with testing.
    • Begin Writing Tutorial Algorithms (these will require less research):
      • Sound Servers: JACK
      • Sound Servers: PulseAudio
      • Planet CCRMA: Repository Configuration
      • Recording: Audacity
      • Synthesizers: SuperCollider
      • Typesetting: LilyPond
      • Typesetting: Frescobaldi
  3. (7 - 13 June):
    • Test previous week's tutorial algorithms.
    • Finish writing tutorial algorithms (these will require more research):
      • Recording: Ardour
      • Synthesizers: FluidSynth/QSynth
      • Synthesizers: Rosegarden
      • Synthesizers: Qtractor
      • Training: GNU Solfege
  4. (14 - 20 June):
    • Test previous week's tutorial algorithms.
    • Review algorithms, seeking possible mistakes or pitfalls, and forewarn about them.
    • Buffer week.
  5. (21 - 27 June):
    • Ensure contact is made with the Docs SIG about the evolution to an "official" document.
    • Begin writing documents on the Fedora Wiki (algorithms will already be on the Wiki):
      • Sound Cards
      • Sound Servers: ALSA, Phonon, and Informational Background
      • Sound Servers: JACK
      • Sound Servers: PulseAudio
      • Planet CCRMA: Informational Background
      • Planet CCRMA: Repository Configuration
      • Recording: Audacity vs. Ardour
      • Recording: Audacity
      • Synthesizers: SuperCollider
      • Typesetting: LilyPond
      • Typesetting: Frescobaldi
  6. (28 June - 4 July): Week of Canada Day
    • Finish writing documents on the Fedora Wiki:
      • Recording: Ardour
      • Synthesizers: FluidSynth/QSynth
      • Synthesizers: Rosegarden
      • Synthesizers: Qtractor
      • Training: GNU Solfege
    • Begin target-audience testing with previous week's material.
  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?
    • Write and Test Optional Sections (Algorithms):
      • Kernel Optimization
      • Webcasting: Icecast
  10. (26 July - 1 August):
    • Finish converting to DocBook XML?
    • Write and Test Optional Sections (Prose):
      • Kernel Optimization
      • Webcasting: Icecast
  11. (2 - 8 August): Week of Another Long Weekend:
    • This is a buffer week, which shall receive no assigned task (except optional tasks).
    • Convert Optional Sections to DocBook XML
  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 Tutorial Topics

(1.) Topics marked as "optional" will be completed as time permits, during project weeks 9, 10, and 11. See the proposed schedule for details.

(2.) Where possible, I will avoid replication of material by referring to existing Fedora Project documentation.

System Tasks

Audio Tasks

Miscellaneous

-Can you set up an appropriate development environment?

Yes; this is not especially difficult.

-Have you met your proposed mentor and members of the associated community?

Yes, they are Rudi Landmann (docs) and Anthony Green (music). I have also been in contact with several mailing lists and IRC channels, and received a few interested responses.

-What is your t-shirt size?

Probably "M".

-Describe a great learning experience you had as a child

Although it is not a single experience, the time that I spent with computers as a child (at about 10-15 years old) has certainly helped to shape my character. I began by simply moving components between machines and changing settings, with no particular goal in mind. This gave me the confidence to begin programming, and eventually move to Linux. Once I did that, the open-source music programs available on Mandrake (yeah - Mandrake) helped me to learn about musical composition. The question, "What can I do to make a particular sound?" is one that still drives me today.

Comments

Add comment

Please see the discussion page for comments.

Retrieved from "https://fedoraproject.org/wiki/Summer_Coding_2010_proposal_-_Fedora_Musicians%27_Guide"