Foretaste/Background

I wrote a paper at one point examining engraving and typesetting practices in music in the past 500 or so years. In it, I examine how up until about 40 years ago. engraving and typesetting was a time honored process. It took time, years of experience, and training into details that was a lifelong learning process.

But, there was a fast track with the advent of the personal computer, which allowed the lay person to harness nearly unbridled productivity. The internet spawned, and all of a sudden there was a market for “automated engraving.” Not long after that point, Finale’s grandfather was born, and into the 90s Sibelius.

I do make an argument in that paper (and in the TheTicklishGuide) that there is a significant inverse correlation between the development of technologies that automate processes and the overall quality of the output of those processes.

The problem is that most programs use a GUI (that’s Graphic User Interface) and many people associate productivity with being able to see what the output is immediately.

Being able to see immediately the outcome, however, is under normal mundane and simple needs just adequate. But much like mentioned in this blog post, things get complicated quickly.

The point I’m trying to make is that real life needs of programs like Finale are beyond their initial adequacy.

LilyPond

I must give a caveat before proceeding: LilyPond preaches a different paradigm on content authoring. By that, I mean, there are many different ways to be productive, and the most common way to content author is a paradigm called What You See Is What You Get (hereafter WYSIWYG). Within this way of thinking, the idea is that what you edit on screen is duplicated in print. Otherwise, programs that author content like Microsoft Office.

This is not how LilyPond authors content. Rather, LilyPond (and programs like LaTeX and LyX) authors content automatically without you being able to preview print matter during the process of authoring. This paradigm is expressed as What You See Is What You Mean (WYSIWYM). It basically means that you focus on content and allow powerful lightweight processors to format that content for you (based on algorithms formed on time tested philosophies and rules).

Content first?

Why not be able to see content as it will print while you are authoring it? It is such a common idea, and many people thing it is quite restrictive to author content without seeing how it will come out. This, however, requires many things:

1. A GUI that has buttons, menus, and macros consumes power (both on the computer and the user)
2. A program that must be germanely deficient and lacking (both from a commercial standpoint and otherwise)
3. A User which knows a lot about format, page layout, page design, and typographical practices
4. A system of output which greatly curtails time spent and automates true quality

Without going into too much detail, these four reasons follow logically from the engendered nature of commercial for-profit software. Designing a GUI is always a question of “what do we leave out in order to make it accessible?” GUIs also encounter limitations, because for a piece of software to have every kind of need imaginable in its interface would be impossible, if not confusing. It is also lacking because default values must cover the most consumers’ needs. It does not lend itself, indeed it lacks, the flexibility one needs to do whatever they want. Finally, when it comes to output, initial input should not take too much time, and the quality that the program controls must be somewhat quickened and autonomous.

But, in the final analysis, this method of generating content is horribly inefficient. I have a friend who has told me, “I would pursue a further degree, but I’m stifled by the idea of producing a thesis or dissertation that looks professional.”

But, what if you could skip the formatting, leave it to the program, and just compose?

Content first!

LilyPond sidesteps most of these issue totally. It is not for profit, has a very minimal GUI (really, just a text editor with a “Compile” menu) and the documentation for its syntax is comprehensive. It uses plain text, meaning it is future proof (no need to worry about files not being read by the most “current” version). But, it is not a programming language – it uses Scheme and various other languages to redact most any semblance of coding jargon. For example, to write note names A B C D E F G, it merely translates to: a b c d e f g in the language. How about note values? Also simple: 1 2 4 8 16 32 64 128 equals whole, half, quarter, eighth, sixteenth, thirty-second, sixty-fourth, and hundred-twenty-eighth notes.

This way of content authoring allows me to do so much when it comes to composition. LilyPond is very much like this in other ways (I go into much more detail in TheTicklishGuide).

Think first, then think last

When we use GUIs, we are attempting to think about two things at the same time. It has been scientifically proven that multitasking is detrimental to productivity. Even if we aren’t actively monitoring the format of the page, we instinctively check it constantly. There is no easy way around this, and yet it seems the world runs on Microsoft Word.

With LilyPond (and others similar to it), it invites you to think first about content, then about layout. LilyPond get’s it right most of the time, but tweaking is not a daunting process. So, It is far simpler to use than any other program like Finale.

In fact, I am participating in an engraving challenge (which has been slow recently) where I succumb to the Finale version. It has taken me many hours to place many notes of complex (and it a couple circumstances impossible) music. Then, what seems like in a flash the LilyPond example is near 75% complete.

Minor objections

Many will raise the objection that it takes a lot of “learning” to use LilyPond before you can use it well. Although the amount of time spent learning LilyPond right the first time can be debated, I want to grant this point in the meantime to raise another point. With Finale, I still have to learn a lot about the program in order to “make it behave.” Why do I think this? Because though the initial learning curve (using objects, click and drag, menus, that sort of thing) is instant gratification, in the long run it doesn’t teach the user how to do anything. It merely shows them how to mimic and get by with the program. If anything, LilyPond allows the user to get by with a lot more than Finale, only needing to rely on as basic a syntax as possible for the end goal. With LilyPond, you spend time with a manual that is well written, and you start trying those examples, and you can see instant output. it looks beautiful, feels beautiful (if you are into that sort of thing), and reads perfectly.

Frankly, I learn more about LilyPond hacking around with the input than I do with Finale, because everything is tied to the GUI. With LilyPond, you learn the basic syntax, learn about the proper way of writing scores, and voilà! You can now understand and write up to the level you discovered. You know what it does, and even if you don’t understand the mechanics of it, you still are intuitive on how to replicate the process again.

Concluding thoughts

LilyPond does not require me to know very much about format. I know a lot about format, page design, but there are a lot of users of LilyPond who just depend on it to “do the right thing everytime.” This doesn’t mean, as open source software, that the software itself is perfect; it is far from it. But, what it does mean is that compared to other commercial engravers, you stand a better chance of having LilyPond do it right the first time than Finale (which, ironically enough, has been through more years of development than LilyPond). I can type a hymn out of the hymnal with perfect look and feel in under 20 minutes. I can transcribe a mesmerizing piece of Rachmaninoff in under 2 days.

There are more reasons to use LilyPond. Overall, however, it is far easier to use than any other software I have had the displeasure of using over the years (and pay for)!