At the Sounding Edge: Article 24

At the two-year mark, Dave revisits some of the core Linux audio applications to see what's new.

This is the 24th column I've written for LinuxJournal.com. That's
two full years of articles dealing directly with issues and news regarding
the ever-expanding Linux audio software scene.

In this month's installment, I look at a few notable developments going
on in that scene today. Then, I present some specific news about how
I'm getting along with LilyPond these days.

I must apologize to readers who expected an article detailing with
LilyPond in my recent series on music notation software. As
Heather Mead pointed out in her On the Web column in last month's issue
of Linux Journal, I've already reviewed the program
in a previous column. However, that review covered
LilyPond at version 2.2.0, almost two years ago, and its
stable release is now at version 2.6.6. You can read the
earlier review here andhere. This
time, I focus on a few of LilyPond's changes since the 2.2.0 release.Facelift++
The following notes are mini-reports on the development status of some
high-profile Linux audio applications. The basic Linux sound system is in
good condition, with mature versions of ALSA, JACK, LADSPA, MidiShare,
libsndfile and other low-to-middle level system components now available. The
engines behind Linux audio applications are running nicely, thanks to
various kernel tunings, and some of those applications have attained the
status of professional usability. Of course, problems remain. Hardware
support is still narrow compared to what's available for Win/Mac audio
people. In addition, configuration difficulties still can be show-stoppers for
new users.

Furthermore, GTK1.2 and Qt3 are looking dated, and some of our
finest representative applications are looking dated along with them.
Fortunately, the new toolkits are here, and they're looking much better,
with attractions beyond the cosmetic. GTK2 and Qt4 have addressed concerns
about deficiencies of the earlier versions, so programmers should enjoy
better programming resources and users should enjoy greater consistency
in their engagement with the program interface. Everyone wins, so it's
no surprise that much recent development is concerned with a major update
to the GUI.

The Ardour development team is porting the original program to GTK2. An
alpha version is available for normal users, but like all alpha-stage
software, the package is strictly for testing. That is, it is admittedly
unstable and has been released only to identify areas demanding critical
response from developers. There is currently no date planned for a beta
release, but much work is going on behind the scenes. I imagine
that Ardour will reach its beta release stage in a relatively short
period of time. Meanwhile, you still can use the excellent Ardour 0.99,
the last stable release of Ardour based on GTK1.2. A bugfix/maintenance
release for 0.99 should be available by press time.Figure 1. Ardour2 (screenshot by Paul Davis)
The Hydrogen drum machine/rhythm programmer is undergoing a facelift
to bring it into the new world of Qt4. However, Hydrogen also is
going through a period of redefinition. When the dust settles, we
may see a very different Hydrogen, one evolved far beyond its original
purpose. The developers are working on some nice design improvements
to the program, including a pattern editor for pitched instruments
and more powerful instrument design capabilities. These and other
new features are under intense discussion on the Hydrogen developers
mail list. You can check out the traffic on thelist
archive.Figure 2. Hydrogen (screenshot by Artemiy
Pavlov)
The first public release of Csound5 is just around the corner; in fact, it may
be on-line by the time you read this article. An extraordinary amount
of work has gone into this release, and its new feature list is far too
lengthy to check here. It might be argued that its most outstanding new
feature is the Csound API, a programmer's interface that makes it
easier to write front-end programs for Csound itself. The API also makes
it easier to use Csound's vast signal processing and synthesis resources within standalone external
applications. Other notable improvements include a huge number of bug
fixes and low-level code improvements, many new opcodes, more thorough
user-level documentation, JACK support, an interface for Python and
easy-to-operate installers for every supported platform. Check this
column for a future report on the public release, but Csound5 is usable
right now. So don't hesitate to experiment with the currently available
releases.

Regular readers of this column know that I'm a big fan of Rick Taube's
Common Music. For those who aren't familiar with it, Common Music is a language
for generating output files and streams intended for targets such
as general-purpose synthesis environments (Csound, Common Lisp Music,
SuperCollider3), music notation programs (Common Music Notation, FOMUS),
and real-time output via the MidiShare and PortMIDI systems. The support
for FOMUS is especially interesting. Common Music now has a hook into
LilyPond, giving users the powers of Common Music's generative algorithms
and LilyPond's outstanding printable output. Real-time
scheduling/receiving in Common Music also has seen much improvement, and
the addition of the PortMIDI interface expands the number of Common
Music's real-time targets. If I had to choose three computer music applications
that I couldn't do without, two might change from day to day,
but I'll always want Common Music.

Ardour, Hydrogen, Csound and Common Music all are multiplatform by
design. Ardour and Hydrogen run on Linux and OSX, thanks to JACK, and
Csound and Common Music always have been available for a wide variety
of platforms, including Windows, Mac and various flavors of UNIX.

Linux audio developers and users will have the opportunity to meet
and greet one another at the next Linux Audio Conference, aka LAC2006.
This event returns to Karlsruhe, Germany, and will again be held at
the wonderful ZKM, the Center for Art and Media Technology in Karlsruhe. The
conference will take place this year April 27-30. The LAC is an important
event for the Linux audio community, so make your reservations now.Into the New Pond
LilyPond's basic usage has changed somewhat since my review of it at version
2.2.0. A default score layout now is assumed, with a soprano clef, a
common-time (that is, 4/4) time signature and a C-major key signature (no
sharps or flats). The screenshot in Figure 2 was produced with these two
lines of LilyPond code:

\version "2.6.3"
{c'4 e'8 g' bes'4 a'8 g' c'4 e'8 g' bes'4 c''}

Figure 3. Simple LilyPond
The "\version" command is not mandatory, but I included it to avoid a
LilyPond compiler warning.

I saved the code as ex-1.ly and processed it with only the default
compiler options:

LilyPond's default layout output format now is PostScript, and the default
conversion format is Adobe PDF. TeX/DVI still is available as an
option, though. The PNG graphics format has been added as an optional LilyPond
output target, and MIDI file output remains available with the "\midi"
command. The "\layout" command has replaced the older "\paper", and it
now is required if you want a printable format along with a MIDI file.

With those changes in place, the code from my earlier profile of LilyPond
still compiles and produces the results seen in that article's
screenshots. For this review I've done something different. I've been
writing some classical guitar pieces, composing them with the help of
a MIDI sequencer, and I've planned all along to prepare LilyPond scores
for them. I used this month's column as the motivation I needed to start
that project.

My pieces are saved as standard MIDI files, but I decided not to use
LilyPond's midi2ly, a utility that converts a MIDI file to a LilyPond
file. I wrote about midi2ly in my previous review, and I saw no reason
to go over that material again. Instead, I decided to prepare the score
manually, to write the code directly to a LilyPond file. It's been a
long while since I worked with LilyPond, so I was essentially learning
it all over again. That was fine with me; I thought it would be a good
way to get intimate with the LilyPond language details.

I began by taking the time necessary to make the first measure of music look
exactly as I wanted it. I copied that code and edited it to create
the second measure and then copied those measures to create the third and
fourth bars. Measure 5 required only slight edits to the code I created for measure
1. Measure 6 introduced new considerations, and after mastering them, I
reused that code throughout the piece. As you can see in Figure 3, this
piece is quite repetitive, lending itself to a fast edit/copy/paste
cycle. I learned the language elements as I needed them, and it didn't
take long to feel at home in the Pond.Figure 4. Excerpt from a LilyPond Score
You can view the LilyPond source code and full PNG display for this
example and othershere. I
should admit that although LilyPond code can be quite elegant, my code is
not subtle at all. However, it is clear and it does the job. I'll keep
working to be a better LilyPond user, though, and I'll update the files
on my site as I improve my LilyPond chops.

By the way, I made good use of two xterms and GhostView while preparing
this piece. I edited my LilyPond code in one window--with vi,
naturally--compiled it in the other window and held GhostView open in
its "watch" condition:

gv --watch prelude.ly &

The display in GhostView updated immediately after each compile. Very
cool.

I must compliment the LilyPond developers for their conscientious
approach to documentation. LilyPond's on-line tutorials and reference
materials have been created to inform clearly and succinctly and to
provide the reader with immediately useful examples. The example images
link to their generating code, and users are encouraged to copy and
paste the example code as desired.

Figure 3 also demonstrates LilyPond's default responses to certain layout
considerations. In measure 6 and all similar measures, the 8th-note stems
were reversed automatically. Notice that time-signatures have been added
at the end of some systems--the first four lines of music--to alert a
sight-reader of a change in meter in the next system.

Notice also that where melody and accompaniment notes overlap, such as
in measure 22, the collision was resolved automatically. Finally, in the
last two measures of the piece (not shown here), the arpeggio signs autosized
themselves to the extent of the chord.

In these and other less noticeable decisions, we see the hands of the
LilyPond designers. It is important to realize that I had nothing to
do with the spacing between notes, the height and direction of their
stems, the shape of the arcs for slurs and ties, the bar numbers, the
fonts in the title areas and many other subtle factors that affect the
appearance and readability of the printed music. These factors are no
mere after-thoughts. The LilyPond developers have attended to the details
of music typesetting to a degree not encountered in any other notation
software. And as a sight-reader, I must emphasize that the resulting
score is not only good-looking, it is beautiful and perfectly readable.

Of course, I can override LilyPond's defaults at any time, for any
purpose. The developers have balanced intelligent defaults with total
flexibility in a way I've encountered in few other applications.

Music typesetting by copper engraving is an arcane and possibly dying
art. Centuries of practice have brought that art to the perfection
seen in the excellent scores published by houses such as Schirmer and
Baerenreiter. Now, computer-aided typesetting has all but replaced the old
way, but notation software too often has failed to reproduce the factors
that went into the quality of the engraver's work. LilyPond's developers
have assumed that no aspect of music notation is too small for their
notice, and their attention to detail shows itself throughout the project.

LilyPond is one of the finest examples of open-source programming
available, a testament to the deep research that has gone--and continues
to go--into its development. Han-wen Nienhuys and Jan Nieuwenhuizen are LilyPond's
core developers, but LilyPond now is the focus of a team of talented
developers dedicated to producing the finest system for music notation and
publication. I've met Jan and Han-wen; they are remarkable and intelligent
fellows who redefine the term "enthusiastic". LilyPond has been their
labor of love for many years, and their passion for excellence shows
in every aspect of the program. It is equally obvious that LilyPond's
community of developers and users share their dedication and passion.Check-Out Time
That's all for this month's column. Next month I'll update my profiles
of the Denemo and NoteEdit music notation editors, both of which support
output formatted for LilyPond. See you then!ResourcesArdour

Dave Phillips is a musician, teacher and writer living in Findlay,
Ohio. He has been an active member of the Linux audio community since
his first contact with Linux in 1995. He is the author of The Book of
Linux Music & Sound, as well as numerous articles inLinux Journal. He can be reached atdlphilp@linux-sound.org.

I'm elated to see that Hydrogen looks like a real professional product. WOW! it has nice faders and knobs and fonts and color and style.

Ardour however, while it's come a long way, and I hope the port to GTK2 will help, still looks like a 'program' rather than a 'product'.

Developers need to realize that no matter how good their product is (or isn't) under the hood, screen shots are the first and foremost impression. If it doesn't look polished, then I'm not using it. Sad but true fact. I doubt I'm alone.

Linux is in serious need of a 'Sound Forge' like wave file editor, and sequencers on par with Logic, Cubase, or Sonar.

I don't look at the screen shots alone and judge a program, and I doubt all others are doing it either. Infact, if a program looks like Logic, Cubase or Sonar, i get sceptic. What have these guys been spending their time on, making software that works good, or looks good? If its too polished, I'm inclined to think the latter. But don't get me wrong, screen shots are important, because they can show very fast the amount of features. But I don't care about if its a gtk1 or gtk2 program, for example. Thats shallow.

However, some people should definitely consider using more impressive screen shots. The SND editor, for example, far exceeds the amounts of features of any other sound editor, including source forge, cool edit, peaks and whatever. So this:screen shot is by far the most humble and modest graphical "promotion" of a program I know of. However, as soon as you start reading the manual, you should get the real picture...