From Fedora Project Wiki

Line 16: Line 16:
=== Impact on the Fedora Community ===
=== Impact on the Fedora Community ===
* Me: The creation of this Guide will allow the Fedora Project to target a new potential 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 know how to use them - but many are of very high quality.
* Me: The creation of this Guide will allow the Fedora Project to target a new potential 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 know 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.  
* 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. [[User:Rlandmann|Rlandmann]] 23:34, 18 May 2010 (UTC)
* Community Member: (to be offered by Vivian)
* Community Member: (to be offered by Vivian)



Revision as of 23:34, 18 May 2010

Important.png
This Is a Draft
This draft is nearly complete. Please leave comments for improvement! Thank you.

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 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 gives the Guide a specific target audience: highly-trained 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 interested user will be able to use the Guide. Even so, the primary purpose of this Guide will be to open the possibilities of open-source software to users who require specialized audio or music software. These users are traditionally stuck paying large sums of money for closed-source software, which they usually lack the time to learn completely.

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 potential 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 know 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: (to be offered by Vivian)

How I Will Keep the Community Informed of my Progress

In addition to the twice-weekly blogging, I intend to publish a weekly summary of my activities to select newsgroups (at least summer-coding-discuss, and music@fedora, docs@fedora, or Planet CCRMA as the communities seem interested). Furthermore, all of my development will take place publicly on the Fedora Wiki. This will inevitably lead to (temporary,) 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 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, a large number of people may already be watching; if they aren't, then it will be easy for me to show them my problem areas. The usual IRC channels and newsgroups are an obvious solution, along with searching Google. 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 have befallen their writers.

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 over the past four years has been involved with 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. 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 a 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 performing career of a Western classical musician. Many years of musical training - topped off by four years of dedicated study - 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.

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

Note 1: Topics marked as "optional" will be completed as time permits, during project weeks 9, 10, and 11. Note 2: Where possible, I will avoid replication of material by referring to existing Fedora Project documentation.

System Tasks

  • Understanding Sound Cards (quasi-optional)
    • What Is a "Sound Card?"
    • How Do I Find Information about my audio interface?
    • How Do I Find Information about my MIDI interface?
    • 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??
  • Typesetting
    • LilyPond
    • Frescobaldi
    • Denemo
  • Training
    • GNU Solfege
  • Webcasting
    • Darkice or Darksnow
    • Icecast Server

Proposed Applications

Sound Servers

  • ALSA, because you can't escape it
  • PulseAudio, because it's difficult to escape
  • 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. The greatest discussion would be in the section about system optimization.

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

Synthesizers and Sequencers

  • 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
  • Qtractor, because it seems to have grown more useful than Rosegarden
  • Alsa Modular Synth, Phasex, or Yoshimi?

Typesetting

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

Training

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

Optional

  • Darkice or Darksnow, and the Icecast server

What Testing May Need to Be Done

  • test on i686, x64 (I can do this)
  • test in KDE, GNOME, and XFCE (I can do this)
  • test in VirtualBox virtual machines (I shouldn't bother with this - volunteers can do it)
  • test with single and multiple sound cards (I can do this)
  • test with USB and FireWire sound cards (I can do only USB)
  • test efficacy with "computer experts" and "non-experts" (I can't do this)

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?

Sort of.

-What is your t-shirt size?

Probably "M".

Comments

Add comment

Please see the discussion page for comments.