The other day my laptop told me Firefox wanted to be updated to version 15.01. Go ahead, I said, and a few minutes later it was done. Firefox is updating itself all the time now, a new one major release every six weeks, which let me tell you doesn’t fit well with the way public-access computers are managed at the library where I work. The reference desk computer was still using version 3 or 6 or something until they had to update it because of that Java bug.

Speaking of version numbers, I’m waiting for Ubuntu 12.10 to come out in October because it will have Emacs 24.2 on it, the latest version of my favourite editor. I’m running 23.3 right now but there are a few things in 24 that I want to use, though I can’t be bothered to compile it from source or use a version from some dude’s repository.

Firefox 15 … Emacs 24 … Firefox is a fairly new program, but Emacs has been around since the 1970s … when will Firefox overtake Emacs? This sounded like a job for R.

First, using Wikipedia’s Firefox release history and Emacs pages, and Jamie Zawinski’s Emacs timeline, I put together a CSV file of versions and dates. Then I fired up R and ran the following:

> library(ggplot2)
> programs <- read.csv("http://www.miskatonic.org/files/se-program-versions.csv")
> programs$Date <- as.Date(programs$Date, format="%B %d, %Y")
> head(programs)
  Program Version       Date
1   Emacs    24.1 2012-06-10
2   Emacs    23.4 2012-01-29
3   Emacs    23.3 2011-03-10
4   Emacs    23.2 2010-05-08
5   Emacs    23.1 2009-07-29
6   Emacs    22.3 2008-09-05
> head(subset(programs, Program == "Firefox"))
   Program Version       Date
18 Firefox      16 2012-10-09
19 Firefox      15 2012-08-28
20 Firefox      14 2012-06-26
21 Firefox      13 2012-06-15
22 Firefox      12 2012-04-24
23 Firefox      11 2012-03-13
> ggplot(programs, aes(y = Version, x = Date, colour = Program))
  + geom_point()
  + geom_smooth(span = 0.5, fill = NA)

That looks like this:

But when will the line meet? When will Firefox overtake Emacs? I had no idea how to do this so I asked on Cross Validated, the statistics Stack Exchange site: How to predict or extend regression lines in ggplot2?

As you can see, I got an answer, and with a bit of fiddling and leaving out early Firefox versions before they went on their rigid schedule I did this:

ggplot(subset(programs, !(Program == "Firefox" & Version < 4)),
  aes(y = Version, x = Date, colour = Program))
  + geom_point()
  + ylim(0,30)
  + xlim(as.Date("1985-01-01"), as.Date("2015-01-01"))
  + stat_smooth(method = lm, fullrange = TRUE)

which gives this chart:

I don’t know how to extract the range where the lines collide, but it looks like in late 2013 Firefox will overtake Emacs with a version number at or under 25. You heard it here first.

(I had a book review published in the fall 2011 issue of Papers of the Bibliographc Society of Canada (vol. 49, no. 2) (table of contents). Here is my original text, which was slightly edited.)

Konstantinos Sp. Staikos, The History of the Library in Western Civilization: From Cassiodorus to Furnival: Classical and Christian Letters, Schools and Libraries in the Monasteries and Universities, Western Book Centres. Trans. Timothy Cullen and Doolie Sloman. New Castle, DE: Oak Knoll Press; Houten, NL: HES & De Graaf, 2010. 500 pp.; US $75.00 ISBN 9781584561811

This is the fourth volume in a series of six. The first three were reviewed in these pages and comments there apply equally well here, and will also, I expect, to the fifth, due in 2012, subtitled “The Renaissance: From Petrarch to Michelangelo.” (The sixth will be a bibliography and index.) Volume one, “From Minos to Cleopatra,” was reviewed by Merrill Distad in the Papers/Cahiers 44 [Spring 2006]: 134-136; volume two, “From Cicero to Hadrian,” by Tana J. Allen in 45 [Fall 2007]: 215-217; and volume three, “From Constantine the Great to Cardinal Bessarion,” by Peter F. McNally in 46 [Spring 2008]: 116-119.

The word for this book is “lavish.” It is “a lavish production with excellent images and easy-on-the-eyes typeface” (Allen) and “lavishly illustrated” (McNally) with over 170 “black-and-white and colour illustrations contained in a lavishly produced format” (Distad).

The first chapter begins with Rome and Italy after Constantine had moved the capital and in a few pages gives an overview of the rest of the book: the growth of Christian writing and scholarship, scriptoria, the crucial role of monks and monasteries, the Carolingian Renaissance, and the rise of universities. The preservation of classical literature through medieval times is where libraries, such as they were, played a key role, and four important Christian scholars involved in this were Boethius, Cassiodorus, Isadore of Seville, and the Venerable Bede. Tertullian (b. 150) begins a discussion of early Christian writers in Latin.

Chapter 2 covers monastic libraries and changes in book production and distribution. St. Jerome’s work process illustrates the practices of the times: he dictated to a notarius and the text was given to a trained and educated scribe who would make an examplar that would be used by copyists in a scriptorium as the basis for more copies. St. Augustine’s personal library is examined (one of many such in the book), and there is discussion of the Bible—so important that the scribe’s work of copying was an apostolic task—and of manuscripts that survived the start of the Early Middle Ages. The chapter ends with the Vivarium, a monastery founded in 538 by Cassiodorus, who “foresaw that with the collapse of political institutions monasteries would play an important part in preserving the Graeco-Roman tradition.”

Chapter 3, “Roman and Early Medieval Britain,” oddly covers nothing about Roman Britain. Monasteries in Britain and Ireland were important in keeping classical knowledge alive, and libraries there became the best in Europe. Some of the best evidence comes through Bede at Jarrow where “there was no comparable collection in continental or insular Europe.”

Chapter 4 is about the Carolingian Renaissance. Englishman Alcuin, who met Charlemagne on a trip to Italy and later joined his court in Aachen, revived the teaching of the seven liberal arts and played a crucial role in saving manuscripts and building libraries. Charlemagne himself built a large library of his own. The chapter also looks at the major monastic libraries of the period, such as St. Martin’s and Corbie Abbey in France and St. Gallen in Switzerland.

As universities began to appear from the twelfth century, and education moved out of the control of monasteries and eventually away from the Church, so too did books and libraries. An early textbook system arose: peciae were chapters of books used as the basis of study; they were written by teachers, then copied, sold, rented, and passed on from student to student. The library of the Sorbonne is discussed in some detail: in 1272 it received a donation of 300 books that doubled its size. In 1286 the books were split into those that circulated and those that were chained. By the mid-1300s the library had 1,720 books, over 300 of them chained: it was the largest university library extant.

Chapter 7 closes the middle ages by looking at a number of individual libraries, beginning with Richard de Bury, an English bishop and diplomat whose Philobiblion is “an essay recording the paths and methods he pursued for the composition of his library … nothing was to stand in the way of his enriching his library, not even the financial factor.” The libraries of Charles V of France, Simon de Plumetot, and Hereford Cathedral are discussed in detail, as are the papal libraries in Avignon and Rome. (The chapter ends with an unrelated but charming and curious section that stands outside the rest of the book, a paean to “the book guardian” and “the lord of the library” from classical times to the Renaissance that will warm the heart of any librarian.)

The final chapter is about architecture, and Staikos, an architect, clearly enjoys it. It is well illustrated with drawings of cupboards and bookcases, plans, diagrams and photographs.

How well does the book cover its subject? McNally’s evaluation holds: “To the question—for whom will this book be of value?—there is no easy answer. Scholars will appreciate the large amounts of literary evidence from many languages. Unease will, however, be felt at the loose interpretive structure. General readers will be fascinated by the wealth of illustrations but overwhelmed by the detail and lack of a compelling narrative…. [T]he overall constructions lacks a firm design…. Serious library historians will wrestle with the remaining chapters, alternately thankful for and frustrated by the lush and unruly detail.”

There are a number of typographical errors (e.g. “expanses pf water” on p. 109, “objects of virtu” on p. 144), but worse are sentences that border on the incomprehensible, such as one beginning “While remembering and to remind of persons who undertook and performed the duties of library superintendents at this point” (p. 363). In chapter eight, footnote 49 reads, “Regarding the abbey of Cluny, see pp. 000-000.” In the index, readers will be confused that Richard de Bury and Richard de Furnival are under R, not D, or B and F, but Peter Abelard is listed as “Abelard Peter.”

As Distad said, “Staikos’s earlier book, The Great Libraries: From Antiquity to the Renaissance (3000 B.C. to A.D. 1600), appeared in 2000 in a larger but equally sumptuous volume…. A comparison of the two elicits a feeling of déjà vu that extends beyond the format to nearly all of the illustrations, as well as large chunks of text, which, though, slightly rearranged and with minimal rephrasing, are virtually the same in both works.” The curious reader is advised to start with it and Scribes and Scholars: A Guide to the Transmission of Greek and Latin Literature by L.D. Reynolds and N.G. Wilson (3rd ed., 2001).

William Denton (York University, Toronto)

I like to keep track of how many days old I am. It’s a memento mori with the added benefit that every thousand days I get to celebrate an extra birthday and have a party. (If you’re curious about how many days old you are, just put your birth date into Wolfram|Alpha and it will tell you.)

Last week I made an app widget for my Android phone to show me the number of days. It looks like this: it’s the black box with the white numbers in it (with the exact number of days obscured, for security, not embarrassment):

(On the left is another widget, and on the right is the Wikipedia app. In case you’re curious, the icons on the top left show that I have voice mail, that there’s a USB connection, that I’m in developer mode, that Tasker is running, and that I’m at home (I use Tasker to trigger some actions automatically when I’m at home). I took this screenshot with DDMS.)

I’ll show you how I made the widget, but first, a step back. Let’s pretend I was born on Unix epoch day, 1 January 1970. Asking Wolfram|Alpha tells us that was 15570 days ago (I’m writing this on 18 August 2012).

Finding the number of days between two dates is a common question asked by people using all programming languages, and a quick web search will turn up lots of examples. Here’s one way to do it in Perl:

#!/usr/bin/env perl

use Date::Calc qw(Delta_Days);

my @date_now = (localtime)[5,4,3];
$date_now[0] += 1900;
$date_now[1]++;

my @date_then = (1970, 1, 1);

my $days = Delta_Days(@date_now, @date_then);
print "$days\n";

Ruby’s Date class lets you subtract one day from the other (and then turn the result into an integer):

#!/usr/bin/env ruby

require 'date'

date_then = Date.parse("1970-01-01")
date_now = Date.today

puts (date_now - date_then).to_i

I used to use a Perl script to tell me how many days old I am, but that meant I had to remember to run it. I wanted to have the number in front of me where I could always see it. For that an app widget is just the thing: “App Widgets are miniature application views that can be embedded in other applications (such as the Home screen) and receive periodic updates.”

I’d never seriously looked into how to write programs for Android, but it turned out to be fairly easy to cobble something very simple together based on some examples people had posted. (Cargo cult programming is always how I get started on something new like this.) Google’s documentation is very well-written and useful.

I started at the Developer Tools site, which covers getting the Android software development kit and installing Android Development Tools, a plugin for Eclipse. I was really impressed with the Eclipse integration. The last time I used Eclipse was for some Ruby on Rails work, and that was nice, but I’d never seriously used it for programming the way some people (especially Java programmers, I guess) do. I had no idea how powerful it was or what a plugin like this could do.

When I got started trying to write a program, Android Training explained all the basics very clearly and thoroughly. The Eclipse plug-in lets you say “make a new Android project” and it sets out all the files you need and starts you off with a simple program you can adapt. Running Your App shows how to run a virtual Android phone for testing, which is fun.

For actually making my app widget, I copied what I saw in these three examples:

• Hello World widget in Android
• How to make a simple Android widget
• Android homescreen widgets: tutorial

Through all of that I was referring to the App Widgets documentation to figure out what something meant or what options I had or what I might add.

There are just four files that make the widget. I think that’s the minimum for any widget.

First, AndroidManifest.xml, which is necessary in any Android application. The full docs on this file explain, “Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Android system, information the system must have before it can run any of the application’s code.”

Mine looks like this. It says it’s an application and there’s a “receiver” (which is how widgets work) named org.miskatonic.daysold.DaysOldWidget (these things are always based on a domain name) and also a “provider” to be found in @xml/daysoldwidgetproviderinfo. All of this is just laying out the basics so Android is hep to the scene.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="org.miskatonic.daysold"
    android:versionCode="1"
    android:versionName="1.1" >

    <uses-sdk
        android:minSdkVersion="8"
        android:targetSdkVersion="15" />

    <application
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/AppTheme" >

        <receiver android:name="org.miskatonic.daysold.DaysOldWidget" android:exported="false">
            <intent-filter>
                <action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
            </intent-filter>
            <meta-data android:name="android.appwidget.provider"
                android:resource="@xml/daysoldwidgetproviderinfo">
                        </meta-data>
            </receiver>

        </application>

</manifest>

The provider is in res/xml/daysoldwidgetprovider.xml and just looks like this. I think it’s saying “I’m this big and I use the widget layout, and I want to be updated every hour, please, or as you call it, every 3600000 milliseonds.”

<appwidget-provider xmlns:android="http://schemas.android.com/apk/res/android"
    android:minWidth="72dp"
    android:minHeight="72dp"
    android:updatePeriodMillis="3600000"
    android:initialLayout="@layout/widget">
</appwidget-provider>

And the widget layout is to be found in res/layout/widget.xml. It sets out height and width of the containing box and then the look of the text box inside it. All I’m doing is putting white text on a black background in a square, which is about as simple as it can get. Imagine how complicated it would get laying a program that actually did something!

<?xml version="1.0" encoding="utf-8"?>

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/layout"
    android:orientation="vertical"
    android:layout_width="72dp"
    android:layout_height="72dp"
    android:layout_margin="12dip"
    android:background="@drawable/myshape"
        >

        <TextView
        android:id="@+id/thewidget"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_margin="8dip"
        android:background="#000000"
        android:text="@string/app_name"
        android:textColor="@android:color/white"
        android:textStyle="bold"
        android:typeface="monospace"
        android:gravity="center_vertical|center_horizontal"
        />

</LinearLayout>

With those files Android knows there’s a box on screen and what it’s supposed to look like and that it’s a widget, but what’s actually going on in the widget? Well, just one simple thing, defined in DaysOldWidget.java: figure out today’s date and then how many days it’s been since my birthday.

package org.miskatonic.daysold;

import java.util.Calendar;
import android.appwidget.AppWidgetManager;
import android.appwidget.AppWidgetProvider;
import android.content.ComponentName;
import android.content.Context;
import android.widget.RemoteViews;
import org.miskatonic.daysold.R;

public class DaysOldWidget extends AppWidgetProvider {

    @Override
    public void onUpdate(Context context, AppWidgetManager appWidgetManager, int[] appWidgetIds) {
        RemoteViews remoteViews;
        ComponentName DaysOldW;
        remoteViews = new RemoteViews(context.getPackageName(), R.layout.widget);
        DaysOldW = new ComponentName(context, DaysOldWidget.class);

        Calendar my_birthday = Calendar.getInstance();
        my_birthday.set(1970,0,1); // Note January is 0 and December is 11.
        Calendar today = Calendar.getInstance();

        long my_birthday_millis = my_birthday.getTimeInMillis();
        long today_millis = today.getTimeInMillis();

        long diff = today_millis - my_birthday_millis;
        long diffDays = diff / (24 * 60 * 60 * 1000);

        remoteViews.setTextViewText(R.id.thewidget, Long.toString(diffDays));
        appWidgetManager.updateAppWidget(DaysOldW, remoteViews );
    }

}

With all that in place, I ran the program in Eclipse (right-click on project name, Run As, Android Application) and the little virtual phone slowly booted up (and once it was running, it stayed running, so retesting was easy). I could long-click on the home screen to add the widget there.

It worked! I exported the application (and signed it and so on) and ended up with Days Old.apk, which I copied to my phone and opened up in a file manager. It asked me if I wanted to install the program, and when I did, voila, I could add the widget to my home screen for real.

So now I have what I wanted: a widget on my phone that shows me how many days old I am. The next step is to add a configuration option so that other people can use the widget but enter their own date of birth. There’s a way to make an Android widget pop up config options when it’s added to the home screen, and if I figure out how to do that and get it working, I’ll release the app and the code and try to get it into Google Play.

I bought a Nexus 7, a small tablet from Google and Asus running Android 4.1. Here are a few notes about it from the point of view of an Ubuntu user.

Here’s what I do when I get something like this:

• Plug it in.
• Copy a Doctor Who video onto it.
• Watch the video.

None of this worked for me right off the bat, partly due to me (from ignorance) and partly due to Google and Asus (from I don’t know what).

I ran FreeBSD for years, until a chain of events led me from my old window manager to GNOME and then to trying Ubuntu and then switching to it. The moment I’ll never forget was when I plugged my printer into my test Ubuntu box. With FreeBSD I’d spent an entire day configuring the thing and even then I couldn’t get it working with the USB cable so I had to use the parallel port. With Ubuntu, I plugged in the USB cable and it said, “I see you’ve plugged in a Brother HL-2040 printer. Would you like to print a test page?” Yes I would! And it worked. Just like normal people, who run Windows or a Mac. And when I plugged in a USB drive it automatically mounted it! I didn’t have to watch /var/log/syslog and figure out what device to mount by hand.

Perhaps I’m spoiled now, but when I plug something in, I expect things to happen. With the Nexus 7, I plugged it in and nothing happened.

Turns out it’s because Android doesn’t support USB any more so you need to use Media Transfer Protocol, which is fine if you run Windows, but I don’t, and I didn’t know anything about this until David Fiander told me. It did say something about being a media device, I admit, but I just ignored that. However, the instructions at Connect your Android Ice Cream Sandwich Phone to Ubuntu for File Access are complete and helpful (though I used /media/Nexus7 as the mount point), but the fact anything like this might be necessary is embarrassing for Ubuntu.

Other options:

• AirDroid, an app that lets you transfer files by HTTP.
• ADB, the Android Debug Bridge, as Dan Scott pointed out. adb push will copy files.
• gMTP, a file manager/media client for MTP-mounted devices.

Copying a Doctor Who video over: I tried all the options except ADB, and I’ll from now on I’ll either mount the file system by hand or use gMTP. I used both to copy a video over and they were fine.

Watching the video: This was a much bigger problem than I’d expected. Out of the box, the Nexus 7 doesn’t play AVI files! I was very surprised. The previous release of Android did. Why doesn’t this? I know video containers and encodings are complicated, but I expect Google to take care of things like that for me. I installed MoboPlayer and MV Player, but they couldn’t handle the AVIs. MoboPlayer suggested some codecs it wanted to download, but it couldn’t find them in the Play Store and choked on downloading them from its own site.

Finally I installed VPlayer and bought a codec package, using the $25 in Play Store money that came with the device. Now AVIs play and there’s no annoying nagware.

This is a sad and embarrassing solution. There should be some FLOSS package that does this, and if you know how to get one working, let me know.

Other bad points:

• There’s no SD card.
• There’s no camera on the back.
• I can’t do voice input into Wolfram Alpha.

Good points:

• It’s a very nice size and it’s light but strong.
• It’s very fast.
• The voice search and Google Now are impressive, though Apple’s doing well with Siri being able to use Wolfram Alpha.

Knowing what I know now, would I recommend it to anyone who already owns something like an Asus Transformer Prime? Probably not. Wait for it to upgrade to Android 4.1, and carry it around in a bag or case instead of your jacket pocket.

If you feel like augmenting your reality by making a virtual copy of my two-volume boxed set of The Compact Edition of the Oxford English Dictionary appear on your table, here’s how.

Step 1. Install Augment on your smartphone or tablet. Augment is an augmented reality application that runs on iOS and Android. It’s easy to download and install: if you’ve got an iPhone you can find it by searching in the App Store, and if you have and Android phone you can find it in Google Play. It’s free, and no sign-up is required.

Step 2. Download a PDF of the Augment marker and print it out. Put it on the table.

You need this becaus Augment is marker-based augmened reality: it looks at what the camera is seeing and if it detects a particular pre-defined pattern (the marker) it will overlay it with something else. Some marker-based AR programs have different markers for different augments, but in Augment there’s just one marker and you choose what object to show on it.

Step 3. Run Augment. Go to the “Cubes Gallery” and search for “compact oed”. Look for the “Compact OED” object (ignore the “Compact Oxford English Dictionary” if you see it—that was a first attempt with the dimensions wrong, which I need to get removed). Click on it to show the full entry, then click on the eye or the description to load up the object.

Step 4. Point the camera on your phone or tablet at the marker on the table. Marvel! And walk around it.

Since it’s my dictionary, I can compare the real one to the virtual. First, here it is beside the marker:

Viewed through Augment, it looks like this from the front:

It looks like I mismeasured the height a bit, but so what. From the right:

From the top (notice the matching dust):

It goes a bit wonky when something is in front of the marker:

From the back:

I made the virtual OED inside Augment, and it was very easy. I took photos of all of the sides of the object, such as this of the front:

(I didn’t pay much attention to lighting, but comparing the real to the virtual it’s easy to see how better photography would help. Still, I think it’s incredible anyway.)

Then I used “Custom Cubes” in Augment to add the pictures to each side of the object and to assign dimensions. Very simple (except that they have height and depth switched, as I consider them, so mind that). I cropped the pictures in the GIMP but you can do it in Augment too.

Augment is very nice. Try making other objects appear! Follow the company at @augmentedev on Twitter if you’re interested.

I saw the Robert Wilson/Philip Glass opera Einstein on the Beach about a month ago and wrote about it here. It was astounding. I’ve kept on listening to it and done some reading about it, and here’s something I found about a very small part of the music, about thirty seconds, that intrigued me.

Open up this audio clip in another window and play it a couple of times. It’s the first fragment of “Knee Play 3.” The knee plays are short pieces that comes between the acts.

Audio clip of the first fragment of “Knee Play 3” from Einstein on the Beach

It’s a lot of numbers, eh? Over and over, changing slightly. Just hearing it on its own I found it hard to understand, and I got curious about how Glass had scored it. What did the singers have in front of them?

Well, I still don’t know what the full score looks like, but here’s what it originally looked like, written in Philip Glass’s own hand, taken from Einstein on the Beach, a limited edition book from 1976 edited by Vicky Alliata:

It’s an algorithm. It’s code.

Here’s what’s going on, as I understand it. The score written down sets out six bars of music, and the whole notes used there indicate the pitches used to sing the music but without getting into finicky details. The double line at the end means the whole thing is repeated.

“8 (4 + 4) x 2” means count eight, four plus four, one-two-three-four one-two-three-our, for each bar in the score (that is, six times), and repeat it (x 2).

Fully expanded, Glass’s formula becomes:

(1) 8 (4 + 4) x 2

    12341234 12341234 12341234 12341234 12341234 12341234
    12341234 12341234 12341234 12341234 12341234 12341234

(2) 7 (4 + 3) x 2

    1234123 1234123 1234123 1234123 1234123 1234123
    1234123 1234123 1234123 1234123 1234123 1234123

(3) 6 (3 + 3) x 2

    123123 123123 123123 123123 123123 123123
    123123 123123 123123 123123 123123 123123

(4) 5 (3 + 2) x 2

    12312 12312 12312 12312 12312 12312
    12312 12312 12312 12312 12312 12312

I don’t know what to make of “count (3 + 2 x 2),” though. If you know what that means I’d like to hear.

See also: Music by Philip Glass, by Philip Glass with Robert T. Jones, which covers Einstein on the Beach, Satyagraha and Akhnaten.

Thanks to Rob van der Bliek and Tim Knight for helping me understand this. Glass uses solfège—where the singer sings the name of a note when singing that note—elsewhere in the opera, and Tim said the counting here reminded him, on similar lines, of the Indian method of solkattu, for speaking rhythms (Glass studied Indian classical music in the 1960s).

There’s something oddly beautiful about how Thunderbird shows part of an email message in a thread that’s been going on so long that it’s deep into quoting and requoting:

Last night I saw the new production of the Philip Glass/Robert Wilson (with Lucinda Childs) opera Einstein on the Beach. It was an astounding performance of an incredible work, and one of the best shows I’ve ever seen. It’s four hours and twenty minutes long—that’s 260 minutes—without any intermission, and though the audience can come and go as they please, most people stayed in their seats the entire time. I did. I didn’t want to miss any of it. It was enthralling and exciting and hypnotic and marvellous.

• Einstein on the Beach (Pomegranate Arts tour official page)
• Einstein on the Beach (Philip Glass official page)
• Einstein on the Beach (unofficial page with many notes)

When I came into the hall, about fifteen minutes early, it had already started.

That’s Kate Moran on the left and Helga Davis on the right. They sat there for a while, just like that, and then the chorus slowly began to walk into the orchestra pit, and then Moran and Davis began to talk. “Knee Play 1” had begun and the opera was underway. The two of them were in all of the “Knee Plays” (which serve as the introduction, intervals between acts, and conclusion), as well as in some of the acts. Both of them were excellent but Kate Moran stood out specially for her work in “Trial/Prison.”

The program showed the original storyboard done by Robert Wilson, the director:

K1 there is “Knee Play 1.” The square in the bottom right is the white square behind the two in the picture I took.

There’s no story to the opera. Or perhaps there is. I don’t know. But what you see in the storyboard is, for some of the acts, all there is. In act two, “Train” (top of the middle column) we see two people at the back of a train. They slowly come out onto the back deck, then they go back in. The Philip Glass Ensemble and the choir are playing. It takes about twenty minutes. It’s repetitive. It’s wonderful.

There are two dances, choreographed by Lucinda Childs, that are glorious and energetic, with the eight dancers (four men and four women) coming together in various combinations, then breaking up and reforming new groups, running and twirling and leaping beautifully.

The final scene, “Spaceship,” I can hardly begin to describe. It follows “Bed,” which (in this production at least—I suspect it was different earlier) is ten minutes of a long bright white rectangle moving from horizontal to vertical and then ascending up to the top of the stage. The soprano sings a beautiful solo. I admit there were a few minute here where my interest flagged.

But then “Spaceship” began. The curtains pull back to show actors and the Ensemble on a three-storey structure at the back of the stage, the musicians playing and the actors doing something with the light display on the back wall that gets brighter and busier and more complex as the act goes on. A boy in a glass box comes up through a trap door and ascends to the top of the stage, then moves back down and up. A man in a glass box moves horizontally across the stage about twenty feet up. Two dancers wave lights around as if directing a ship in for a landing. A man flies across the stage a few times. The choir is singing. The band is playing. Then the curtain comes down, the music keeps playing, and a little toy rocket in a spotlight moves up from the floor, stage right, to the top, stage left. Then the curtains open again and we see it all again, with the lights and actors and musicians and flying people.

And then in the last “Knee Play” it’s back to Kate Doran and Helga Davis, plus a bus driver (whose bus is in the same spot as the white square at the start) who tells a touching story about two lovers in a park.

I’ll never forget it. If you have a chance to see it, go.

Further reading: Three relevant articles from The Economist:

• Breaking the waves: An avant-garde opera on a rare world tour
• The music of Philip Glass: Still crazy after all these years
• Lucinda Childs’s choreography: Everything old becomes new again