Baby Tree Frogs

I certainly didn’t intend to spend this much time away from the blog, but instead I got a lot of work done.

It’s nice now, after just one day of writing full documents (rather than working on just the basics), to be able to see a lot of text being written in one day.  It makes me feel much more productive!

Development of the Musicians’ Guide is going well, and the biggest obstacle that I’m encountering is the shortcomings of Wiki syntax.  While knowing where I am in the text (in the middle of a homogeneous chunk of pure characters) is a problem quickly-solved, but I’ve gotten myself into a few good messes (some of which I have yet to extract myself from) with lists.  Unfortunately, I can’t use the # and * markup in many cases, because of the <code> and <pre> blocks that I use to demonstreate LilyPond and SuperCollider code examples.  I expect that this kind of problem will stay with me when I make the transition to DocBook XML, but I’m sure there will be time to find a better tool (then KWrite… like Kate) or a better method of writing/indentation (which I currently can’t use or else the wiki will create boxes around my text!)

Advertisements

Musicians’ Guide: Status Report I

“A lot more work” seems to be stretching into ever more work.  I’m wondering now whether it was a good idea to write the documents in two stages, separating the instructive algorithms from the other explanations and information.  It seemed to make some sort of sense when I was contemplating how to break the project into stages.  Furthermore, the ability to work on a variety of software over a relatively short period seems to be having its own benefits.  So long as I stick to my plan, it should all turn out.

Both as a personal note, and as a means of transparency, here is what remains to be done for algorithms:
– JACK: Write about QjackCtl’s “Patch Bay” (easy)
– Ardour: Mixing, Editing, Exporting (awaiting audio files for Mix & Ed; Exp is easy)
– SuperCollider: exporting (will be “record it with Ardour”) and explanation of thought-process for “Method One” (moderate)
– FluidSynth: how to get & install a SoundFont (install is easy; get I don’t know… )
– Qtractor: Use-case demonstration (easy; just takes time)
– LilyPond: piano score (moderate) and orchestral score (difficult)
– Frescobaldi: Maybe I’ll just say to refer to LilyPond, since I’m using Frescobaldi in those tutorials; in that case, F is done.

I’m glad that I did that.  There’s still a lot to do!  It makes me think that I should adjust the following milestone for draft documents, or at least create a priority-list.  In particular, I’m thinking that Rosegarden should be put on the back-burner.

Schedule Buffers, Fedora Community, and Lazy Musicians.

It’s a good thing that I planned the week-long buffer zones at the end of major would-be milestones.  In part, I did that because I know that things always take longer than they seem like they should – and they are taking longer!  There haven’t been any problems (aside from the odd software bug), so it’s probably from a lack of experience that I didn’t know exactly how much time to plan.  But that’s okay.

On a related note, a big factor in my ability to keep working (that is, the reason I haven’t run into any problems) is the tremendous support that’s been provided by everybody.  My mentors have, of course, been doing their part in answering queries promptly, but nobody knows everything.  External sources, like the SuperCollider mailing list, and especially the good people of Freenode’s #opensourcemusicians channel have been quick to volunteer advice and encouragement when needed.  It is heartening to experience the open-source culture from a contributor’s perspective, which is new to me.  The open-source way, among other things, focusses on the idea that individual users contribute only a small portion, but that it is these small portions which together build something great.  The Fedora Project, and the Docs SIG (with whom I have been working), is particularly good at encouraging everybody to do their small part.

Another factor that encourages me to keep working is that, regardless of what sort of documentation I find, the exact sort of documents that I’ve been working on still seem to be missing from most music software.  This makes a certain amount of sense.  For my target audience, however, it does not.  Musicians in university music programs are often forced to use advanced and highly-specialized computer programs.  We don’t have time to really learn how to use the programs, so instead we simply learn what we need.  If open-source software doesn’t provide a way to learn the software quickly like this, then it’s not likely to be chosen over more-familiar proprietary software.

Talking to some of my peers has encouraged them to investigate open-source solutions for tasks where they would traditionally have used proprietary software.  I think that the Musicians’ Guide’s use-case-focussed instruction will provide an easy and useful way for them to learn software.  I’ve been contemplating an “embedded glossary” kind of lay-out, where the means to accomplish a task form the core of every chapter, with musical and technical definitions and explanations included in a manner that makes it easy to skip them if you’re in a hurry.  If you have the time, you can read the technical explanations.  If you’re not a trained musicians, you can read the musical explanations, too.  In this way, the document will serve the needs of both amateurs and professionals.

With prose-form writing scheduled to begin within the week, I would appreciate any sort of feedback or suggestions that the community can provide.

I Didn’t Intend to Write about Interface Design…

Now that I’m settling into the flow, development of Fedora’s upcoming Musicians’ Guide (my Summer Coding 2010 project) is progressing much more quickly.  The most surprising thing is that, even if I already know the software well, it can take quite a bit of research and thought to document a method for accomplishing even simple tasks!  It’s not every day that users and developers are forced to think carefully about what they’re trying to do.  Considering some confusing GUI layouts, which can be nearly impossible to figure out unless you’ve already used similar(ly opaque) software, it’s little wonder that more musicians aren’t jumping onto the open-source bandwagon.  Sometimes, of course, there really is no better way to represent the features required.  Software that is designed to imitate a hardware device is probably better off looking like that device than trying to re-invent an intuitive interface.

Testing is now underway for some of the algorithms.  In particular, PulseAudio and JACK configurations need to be tested.  Please visit this web page for details, if you would like to help out.  Remember, the more people who test these algorithms, the better they will be, and the more useful the resulting documentation will be.  Besides, we may be able to unearth a few software bugs here and there!

The three most difficult (for me) programs are coming up this week: Ardour, Qtractor, and Rosegarden.  I want to be sure to capture the unique capabilities of each program, rather than simply writing about the same tasks with three different applications.  I expect to encounter the greatest difficulty with Qtractor, which is still “Alpha” software, and seems to lack any sort of documentation at all.  Perhaps they would be interested in adapting a chapter of this Guide when it’s finished…

Reflections and Refractions After One Week

N.B. By “Reflections and Refractions,” I mean to mock a scholarly article or fifteen.

Here’s another cliche: It’s hard to believe that we’re already one week into the Summer Coding 2010 process!

Really, though, it is hard to believe.  It seems like I’ve simultaneously accomplished nothing, and accomplished a great deal.  That’s how the week has been going for me.  It’s slow work, chugging away, reading all 300 ways to rid your Fedora Linux system of PulseAudio once and for all.  None of them work, by the way.  While you can easily remove PulseAudio from your system, it’s another thing entirely to get sound working again.

Then there are the areas where I have done quite a lot: surprisingly, the Audacity tutorial was easy to write.  I think that its readers will have a good understanding of how to use the software, especially if they download the audio examples that will be provided.  I even found a bug!

On the other hand, I was supposed to have finished the LilyPond/Frescobaldi tutorial algorithms today, but I didn’t.  I did finish one of the three use cases, but the piano score and orchestral score remain to be written.  Part of the problem here is that I’m going to rely on the excellent LilyPond documentation to provide an introduction to LilyPond.  However, I’m not exactly sure what the user should be expected to know by the time they get to my tutorials.  It will be important to sort this out eventually, so that I can decide on exactly how much detail is required for these sections.

Tomorrow (Thursday), I will be taking a day off, spending it in Toronto, concluded by a concert of the Toronto Symphony Orhcestra with Yundi Li as soloist.  Bruckner’s ninth symphony is on the program, and it’s one of my favourite musical works.  It always inspires me, which is good, because Friday and Saturday will be dedicated to SuperCollider!

Being behind schedule doesn’t concern me yet.  There are lots of buffer zones in the plan, and I’m confident that I will be able to finish the LilyPond/Frescobaldi sections in time.  Also, please don’t contact me with techniques for PulseAudio.  It did eventually get sorted out, I think!

Summer Coding Begins; Documentation for Music Software Is in the Works!

As the Summer Coding SIG announced this summer’s approved projects last Thursday, I was delighted to find my proposal on the list. The chance to contribute to the Fedora community this summer, with dedicated help from experienced Fedora Project community members, is certainly a first for me. I’m really looking forward to realizing my proposal this summer!

The upcoming Musicians’ Guide is a project that I proposed to help fill a knowledge gap. If you’ve ever tried to use a proprietary music or audio program (be it ProTools, Finale, or Cubase), then you know that these programs have a tendency to be very complex and very expensive. There are open-source equivalents for most of the proprietary software that’s available, but for a number of reasons, they are usually obscure and poorly-understood.

Believe it or not, Fedora Linux happens to be an excellent platform for audio production and other musical tasks. Especially with the additional “Planet CCRMA at Home” repositories hosted by Stanford University, the possibilities of Fedora are nearly endless. The guide will discuss software such as Audacity, Ardour, SuperCollider, LilyPond, and GNU Solfege. Instructions for simple tasks (like opening and saving files) can be found elsewhere, so there will be a special focus on knowing which tool to use for which task (Audacity vs. Ardour, or Qtractor vs. Rosegarden, for example), and on applying tutorial topics to real-world creative situations. Though it may be great to know how to save a ten-second audio clip of you making a “mmm” noise, the real power of computers comes in understanding how to transform ten seconds of “mmm” into ten minutes of music.

As a Fedora user, you are either directly or indirectly helping to support the Summer Coding 2010 program. Most of these projects wouldn’t have happened without the program, so on behalf of all students and mentors working with Summer Coding 2010, I invite you to enjoy your flight, and thank you for choosing Fedora Linux.

All Summer Coding 2010 projects will be making regular posts to Planet Fedora throughout the development process.