From Fedora Project Wiki

Revision as of 04:29, 12 May 2010 by Crantila (talk | contribs) (→‎Proposed Schedule: changed formatting and section name)

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

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

The following list is in the following format:

Week Number:

  1. (24 - 30 May):
    • determine specific tasks to include
  2. (31 May - 6 June):
    • generate algorithms for specific tasks
  3. (7 - 13 June):
    • Testing Algorithms on Various Platforms
  4. (14 - 20 June):
    • Testing Algorithms and Writing Documents
  5. (21 - 27 June):
    • Testing Algorithms and Writing Documents
  6. (28 June - 4 July): Week of Canada Day
    • Writing Documents
  7. (5 - 11 July): MIDTERM - bulk of the writing must be completed
    • this week, review for errors/pitfalls, and forewarn about them
  8. (12 - 18 July):
    • audience testing and revising
  9. (19 - 25 July):
    • audience testing and revising
  10. (26 July - 1 August):
    • audience testing and revising
  11. (2 - 8 August): Week of Another Long Weekend:
    • audience testing and revising
    • re-writing into Publican?
  12. (9 August): Project Completion.

What Research Needs to Be Done

Precedents

PlanetCCRMA

  • read the Planet CCRMA documentation, which will be included basically as-is (algorithms-wise, at least?!)
  • will there be a timely release for F13? F14?

Kernels (optional)

  • is it necessary to apply an RT patch to a standard Fedora kernel?
  • how to compile one's own kernel
  • how to compile an RT-patched kernel
  • what will cause poor audio performance?

Tasks/Programs

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.

Retrieved from "https://fedoraproject.org/w/index.php?title=Summer_Coding_2010_proposal_-_Fedora_Musicians%27_Guide&oldid=173197"