Summer Coding 2010 proposal - Fedora Musicians' Guide

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.

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 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

• Me: The creation of this Guide will allow the Fedora Project to target a new user base, which would otherwise be unlikely to switch. Certain sections of the Guide may help to illustrate the shortcomings of audio and music software on Fedora or Linux, giving other contributors a set of areas to focus attention. Conversely, certain sections may highlight some of Fedora's (or Linux's) hidden strengths - areas that Fedora can advertise its advanced capabilities. I expect this to be the case with most of the programs, because few musicians know about them - or how to use them - but many are of very high quality.
• Mentor: This guide will present Fedora as a useful tool for creators and performers of music. I believe that this will expand the Fedora community into a specific class of users for whom we have offered little formal support up to now. As Christopher points out, it also assists the existing Fedora community by identifying specific shortcomings and unresolved problems. Rlandmann 23:34, 18 May 2010 (UTC)
• Community Member: "As a graduate student in music and through my lengthy experience with closed-source music software, I can see several positive ways in which the completion of this guide could benefit the Fedora and music communities. Firstly, the guide would make open-source programs like LilyPond more accessible and easier to understand. As a result, I believe that more musicians would be willing to convert to these programs rather than to pay big sums of money for closed-sourced programs that do the same thing. As well, I think that this guide would allow amateur and professional musicians to explore other aspects of music-making by discovering programs through this guide that would let them do so." (Vivian L., email: vivluong from Google's free webmail service)

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

• 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.

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.

• Tutorial: One topic or process covered in the guide, such as "Installation of Ardour."
• 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):
   • 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

• Understanding Sound Cards
  • What Is a "Sound Card?"
  • How Do I Find Information about my audio interface? (optional)
  • How Do I Find Information about my MIDI interface? (optional)
  • How Do I Know Which Input/Output Port to Use?
• Understanding Sound Servers
  • What a Sound Server Is
  • Advanced Linux Sound Architecture (ALSA)
    • What ALSA Is, and Why It Exists
  • PulseAudio
    • What PulseAudio Is, and Why It Exists
    • Knowing When to Use PulseAudio
    • How to Disable PulseAudio
    • How to Remove PulseAudio
  • JACK Advanced Connection Kit
    • What JACK Is, and Why It Exists
    • Knowing When to Use JACK
    • How to Setup Your System for JACK (will refer to kernel section, later)
    • Controlling JACK with QjackCtl
  • Phonon
    • What Phonon Is, and Why It Exists
    • Knowing When to Use Phonon
• Planet CCRMA at Home
  • What Planet CCRMA Is, and Why It Exists
  • Knowing Whether You Should Use Planet CCRMA (including risks & benefits of third-party repositories)
  • Adding the Planet CCRMA Repositories
  • Downloading and Installing Software from Planet CCRMA
• Optimizing the Linux Kernel for Audio Applications (optional, but highly desired - at least CCRMA)
  • What Is a Realtime Kernel? (including "What is processor scheduling?")
  • Using a Pre-built Realtime Kernel from Planet CCRMA (including "Planet CCRMA's kernels may be older than Fedora's")
  • Building Your Own Audio-Optimized Kernel (of course, with appropriate disclaimers)
  • Other Possible Optimizations (this will primarily be the removal of unused device drivers)

Audio Tasks

• Recording
  • Knowing Whether to Use Audacity or Ardour
  • Audacity
    • Requirements and Installation
    • Configuration
    • Recording a Session
    • Saving and Exporting
    • Using Simple Effects
  • Ardour
    • Requirements and Installation
    • Configuration
    • Recording a Session
    • Saving and Exporting
    • Something Complex
    • Something else Complex
• Synthesizers and Sequencers
  • SuperCollider
    • What Is SuperCollider?
    • The Different Parts of SC
    • Requirements and Installation
    • Using GEdit to write and run code/programs/music
    • Composing with SuperCollider (Method 1)
    • Composing with SuperCollider (Method 2) (N.B. these 'methods' are intended to help users learn compositional strategies... the software is not particularly inviting)
    • Exporting Sound Files
  • FluidSynth
    • What Is FluidSynth?
    • About SoundFonts?
    • Requirements and Installation
    • Configuration
    • QSynth: Introduction and Installation
    • Using JACK with FluidSynth
    • Redirecting Output for Recording
  • Qtractor & Rosegarden: These will be in separate sections, but I'll need to learn the programs better before deciding what to do.
• Typesetting
  • LilyPond
    • What LilyPond Is
    • How LilyPond Works (and "LP is best used with other programs to help it")
    • Installation (and Configuration, if Required)
    • A Brief Introduction to LilyPond Syntax
      • Working on a Counterpoint Exercise (this is a simple score)
      • Working on a Piano Score (these can get quite complex; we'll focus on issues unique to piano music)
      • Working on an Large Ensemble Score (probably a work for orchestra; we'll focus on issues unique to large ensemble music)
  • Frescobaldi (N.B. this is a modified text editor for use specifically with LilyPond files)
    • What Frescobaldi Is, and How It Can Help
    • Installation and Configuration
    • The Basic Features of Frescobaldi
    • The Advanced Features of Frescobaldi
• Aural Skills Training
  • GNU Solfege
    • I haven't used this in years, and it has changed quite a lot. I'll have to re-learn the software, then decide what to do.
• Webcasting (highly optional - would make a great addition)
  • Darkice or Darksnow
  • Icecast Server
  • If I end up covering these applications, tutorial topics can be decided later.

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.