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 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?
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. I expect this to be the case with most of the programs (except Audacity, which is already well-known), because few musicians know about them - or know how to use them - but such programs as Ardour, LilyPond, and SuperCollider are of very high quality.
- Mentor: ???
- Community Member: ???
How I Will Keep the Community Informed of my Progress
In addition to the twice-weekly requisite blogging, I intend to publish a weekly summary of my activities to select newsgroups (at least summer-coding-discuss, and music@fedora or planet-ccrma if requested). 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 the project's progress. Also, it allows the widest possible target-audience testing.
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.
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
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:
- Open Terminal.
- Type
sudo yum update
- When it stops, type
y
- 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:
- (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.
- (31 May - 6 June):
- Finalize tasks/tutorial topics.
- Revise schedule as needed to incorporate the finalized tutorial topics.
- Begin writing tutorial algorithms.
- (7 - 13 June):
- Test previous week's tutorial algorithms.
- Finish writing tutorial algorithms.
- (14 - 20 June):
- Test previous week's tutorial algorithms.
- Review algorithms, seeking possible mistakes or pitfalls, and forewarn about them.
- (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.
- (28 June - 4 July): Week of Canada Day
- Finish writing documents on the Fedora Wiki.
- Begin target-audience testing.
- (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.
- (12 - 18 July):
- Finish target-audience testing.
- Finish revising documents to incorporate comments of target-audience tests.
- (19 - 25 July):
- Convert document to DocBook XML?
- (26 July - 1 August):
- Finish converting to DocBook XML?
- (2 - 8 August): Week of Another Long Weekend:
- This is a buffer week, which shall receive no assigned task.
- (9 August): Project Completion.
- Write final report, due 16 August.
- Create "snapshot" of all documents, due 16 August.
- Write evaluation, due 16 August.
- Return to real life.
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 itPulseAudio
, 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 introducePlanet CCRMA
, it's full of features but relatively simple, and I know it better thanCsound
FluidSynth
with QSynth, because it's graphical, works withJACK
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?)
Proposed Tutorial Topics
System Tasks
- Configuring Planet CCRMA
- Optimizing for JACK
- Compiling or Downloading/Installing a real-time kernel
Audio Tasks
- List of applications goes here
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.
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?
No!
-What is your t-shirt size?
Probably "M".
Comments
Please see the discussion page for comments.