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

Proposed Schedule

Week 1 (24 - 30 May): determine specific tasks to include

Week 2 (31 May - 6 June): generate algorithms for specific tasks

Week 3 (7 - 13 June): Testing Algorithms on Various Platforms

Week 4 (14 - 20 June): Testing Algorithms and Writing Documents

Week 5 (21 - 27 June): Testing Algorithms and Writing Documents

Week 6 (28 June - 4 July): Week of Canada Day: Writing Documents

Week 7 (5 - 11 July): MIDTERM - bulk of the writing must be completed // this week, review for errors/pitfalls, and forewarn about them

Week 8 (12 - 18 July): audience testing and revising

Week 9 (19 - 25 July): audience testing and revising

Week 10 (26 July - 1 August): audience testing and revising

Week 11 (2 - 8 August): Week of Another Long Weekend: audience testing and revising / re-writing into Publican?

Week 12 (9 August): Project Completion.

What Research Needs to Be Done

Precedents

read the Fedora User Guide and Installation Guide for hints
find out what is already well-documented & link it in
see:

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

find out which tasks I want to use (synthesizer, recording/mixer, notated scores, aural skills)
- http://ccrma.stanford.edu/planetccrma/software/packages.html (including "Roadmap")
- http://en.wikipedia.org/wiki/List_of_Linux_audio_software
- http://sound.condorow.net/
- http://wiki.linuxaudio.org/apps/start
- http://linuxaudio.org/
- https://fedoraproject.org/wiki/AudioCreation
- distros
  - http://www.64studio.com/ (!)
  - http://en.wikipedia.org/wiki/Ubuntu_Studio (http://ubuntustudio.org/) -- Wikipedia page has a list of included applications (!)
  - http://www.dynebolic.org/ (!)
  - http://proaudio.tuxfamily.org/wiki/index.php?title=Main_Page
  - JAD: (jacklab.net) -- wherever it went
  - http://openartisthq.org/
  - http://puredyne.goto10.org/
- categories
  - graphical/text audio programming: gAlan, Ingen, jMax, OpenSoundWorld, Pure Data, ChucK, Csound, Nyquist, SuperCollider
  - DJ tools: Digital-Scratch, DJPlay, Mixxx, TerminatorX, UltraMixer, xwax
  - drum machines: csDrummer, Hydrogen, Jackbeat
  - recording, editing, mastering: Ardour, Audacity, Buzztard (synthesis?), Gnome Wave Cleaner, Jokosher, LMMS (Linux MultiMedia Studio), MusE, NoteEdit, MuseScore (not in CCRMA?), Renoise (DAW), ReZound (like Audacity?), Qtractor (DAW), Rosegaren (DAW??), seq24 (loop-based MIDI sequencer), Sweep ("digital audio editor"), mscore
  - sound servers (?): Phonon, JACK, PulseAudio, NAS(?)
  - patch bays: Qjackctl, Patchage [ do both if possible ]
  - synthesizers: FluidSynth (with QSynth), Bristol (organ synthesis), TiMidity++ (?), ZynAddSubFX?
  - effects processing: LADSPA, DSSI?, LinuxDSP?, Jack Rack
  - no: format transcoding
  - no: radio broadcasting
  - no: radio listening
  - no: tablature, guitar, fretted instrument software
  - music study software: GNU Solfege, Javtronome, multi-metronome, GTick,
- find out which programs to use for the tasks
- find out which specific tasks will require specific instructions

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.

About my Project

Name: Fedora Musicians' Guide
Idea Page: Summer Coding 2010 ideas - Fedora Musicians' Guide

Comments

Add comment

Search