Evan Lenz

Short blog post, in bullet points:

• I’m attending SXSW Interactive very soon. PianoNinja was accepted as a semi-finalist in the ScreenBurn Game Design Competition! If my presentation is selected as a finalist, I’ll get to present a live 5-minute pitch for the judges.
• I’m working on a reference implementation for Inline XBRL. I had responded to their RFP for XSLT style sheet for extracting XBRL 2.1 from HTML documents with embedded Inline XBRL, and they chose my proposal. They’ve been very pleasant to work with, and the work is coming right along.
• I’m also working on a really cool SVG and XSL-FO project, generating SVG-based flow-chart diagrams.
• I’ve started Twittering. This may give me more excuses not to blog. So follow me! Disclaimer: we’ll see how long it lasts.

That’s all for now. See you again in 6 months. 🙂

A common way to help users orient themselves on the chromatic Janko keyboard is to color some of the keys black, corresponding to the black keys on the traditional diatonic piano keyboard. (The actual Janko keyboard doesn’t use narrower keys on the upper row, so the pictures below are a bit misleading in that regard.)

Below are six keyboard coloring schemes. The first three are ways of coloring a chromatic keyboard. The second three are ways of coloring a diatonic keyboard. Here’s a legend for the six variations below:

1. Chromatic keyboard with chromatic coloring
2. Chromatic keyboard with diatonic coloring
3. Same as #2, using opposite colors
4. Diatonic keyboard with diatonic coloring
5. Diatonic keyboard with chromatic coloring
6. Same as #5, using opposite colors

[I’m trying out a new drawing program, so please excuse the big “UNREGISTERED” watermark. If I end up registering it, I’ll replace the image, or better yet, break it into six images. Okay, I know. It’s ridiculous. But I need to go to bed.]

These were inspired by a photo that Paul Morris posted to the MNMA forum, in which he had physically used black tape and white tape to achieve the coloring in #5 above on his traditional keyboard.

A few weeks ago, I was sitting at the piano and contemplating what I had been learning about the Janko keyboard. I was thinking about all the different scale patterns on the traditional piano keyboard and how different they are. There are 12 of them. (I would tend not to count the minor key scales separately, since they’re essentially just offsets from the major scale, as are the other modes.) Johannes Drinda introduced the Janko keyboard to me and in that same email wrote:

The advantage of the uniform Janko keyboard pattern is mind-boggling:
The Janko keyboard pattern does away with practicing scales, would you believe?! This is the true reason, why so many hobby musicians (like me!) got stuck with playing mostly in C-major & A-minor scales and lost out on a great deal of musical joys and creativity.
With Janko one only needs to learn one major and one minor scale-pattern. From then on one can play all 24 major & minor scales.

As I sat at the piano considering these words, I realized that there are really twice as many scales as that, if you count both hands separately. My left hand is not a copy of my right hand. It’s a mirror image of it. The muscle movements and fingering for playing D-flat major in my right hand are much different than the movements and fingering for playing it in my left hand. So then there are actually 24 different scale patterns to learn (12 for the left hand, and 12 for the right hand), or if you count major and minor scales separately (as Johannes did in his email above), then there are 48 separate scales to learn (24 for the left hand, and 24 for the right hand).

The fact that one hand mirrors the other also reminded me of Vincent Persichetti‘s “Mirror Etudes”, a selection of which I played in my junior or senior recital in college (I can’t remember which). One thing I liked about this piece is that all I really had to do was learn the right hand, and then make the same movements in my left hand, taking advantage of the fact that the piano keyboard mirrors itself (pivoting around D and A-flat). Persichetti used this algorithmic device (where one hand’s part is a simple function of the other hand’s part) to very nice effect, perhaps in some ways in spite of the device.

The next thought I had was: “What if each hand had its own keyboard, so that the same movements and fingerings would produce the same notes?” If I traverse the five-finger position from my thumb to my pinky in my right hand, then the pitches go up (get higher). On a regular piano, if I do the same thing in my left hand, they go lower. That’s the mismatch. What if they both went higher, so that playing a given part in the right hand felt exactly like playing that part in the left hand? I then supposed that this would require two different keyboards: one for my left hand and one for my right hand. The right-hand keyboard could be the “normal” one, and the left-hand keyboard would be reversed: moving to the left causes the pitches to rise, and moving to the right causes them to descend. We could then speak, instead of moving left or right, of moving outward or away from the body (ascending in pitch), and inward or toward the body (descending in pitch). With a setup like this, if you act as if you’re playing the Persichetti etudes on a traditional keyboard, you’d now actually be playing both hands in unison (robbing the piece of its character, but that’s not the point).

Google can have a tendency to quash creative thinking. What seems like an original idea turns out to be not so original. Then again, it can also have a validating effect. Regardless, someone has already had this idea (and patented it). There’s also a diagram showing how the left-hand keyboard is re-mapped. Actually, now that I look at the diagram, I see that it’s not quite the same as what I had in mind. I was thinking of just reversing a traditional piano keyboard. The diagram for this patent shows a 6-6 pattern (like Janko) for both keyboards. So in that case I suppose you could truly say that the user would only need to learn 1 single diatonic scale pattern, as opposed to 24. Not bad.

But that’s not all. A pianist named Christopher Seed has actually built a left-handed piano. (Be sure to check out his videos page too, where he shows off his ambidexterity.) Not only that, but his website offers a simple hardware module called The Keyboard Mirror that transforms a MIDI keyboard into a left-handed (reversed) MIDI keyboard! This probably wouldn’t be too difficult to implement in software too. So to try my idea out, all I’d need is two MIDI keyboards, one unmodified and one with the Keyboard Mirror plugged into it. To keep things really interesting, I could try switching them around: not only right/normal, left/reversed; but also left/normal, right/reversed.

I just had a funny thought: playing Persichetti’s Mirror Etudes on a left-handed piano would be almost exactly like playing them on a traditional piano! (Except that when you try to voice the upper parts, you’d start wondering why the bass part is getting louder!)

Now, for a real mind-bending exercise, try playing the Mirror Etudes using a left-handed (reversed) keyboard for the left hand and a traditional (not reversed) keyboard for the right hand. Of course, that seems about as sensible as using Vim with a Dvorak keyboard.

Update: When I wrote that last paragraph earlier tonight, I hadn’t realized that playing the actual Mirror Etudes using symmetrical manuals would be “as if” you were playing both hands in unison on a traditional keyboard. The simplicity of this two-way function (reverseHalf mirrored = unison; reverseHalf unison = mirrored) obviously hasn’t sunken in yet, since it’s still all just up in my head. Yes, I’ve gotta try this out!

There has been some recent discussion in the MNMA forum about an alternative version of Klavarskribo that its inventor (Cornelis Pot) had designed for chromatic, 6-6 keyboards (i.e. keyboards having 6 white keys and 6 black keys in each octave, as opposed to 7 white keys and 5 black keys). Below is my attempt at reconstructing an image from a verbal description (posted in the forum) of an image that was published in a Dutch article in the February 1972 issue of Klavar-Nieuws:

The above example contains all 12 major triads (with doubled roots), traversing over them in two sequences that correspond to the two whole-tone scales. As you can see, there are just two keyboard patterns to learn. (With a Janko keyboard that has more than just two rows of keys, then there’s really just one keyboard pattern to learn. To move up a half step, you’d just shift from the first and second rows to the second and third rows, keeping your hand in the same position.) A comparison with the Klavarskribo equivalent for the traditional piano keyboard shows just how irregular the traditional keyboard is, and how many patterns you have to learn within those same 12 keys (for chords, scales, etc.).

Below are the first six chords (in regular Klavarskribo notation), corresponding to the whole-tone scale starting on C. One thing that was apparently not made explicit in the Klavar-Nieuws article was which key is indicated by the thicker vertical lines in the 6-6 notation above. In my transcription to regular Klavarskribo, I just chose a mapping: B for the thicker lines so that C lands just to the right of each thicker vertical line in the 6-6 notation. Thus, the first sequence would then start with the C-Major chord:

And here’s the second sequence, traversing the whole-tone scale starting on D-flat:

As you can see, there’s nothing in these sequences that approaches the regularity of the 6-6 keyboard patterns. There’s a lot to discuss in comparing the two keyboard layouts—enough to leave for another blog post.

The message in the MNMA forum that described the 6-6 Klavar notation contained lots of fascinating insights, along with quotes relating to the 6-6 keyboard from a letter written by Pot. I wish I could link to it directly. The problem is that the MNMA forum messages are currently only accessible to members (although anyone can join). That may (hopefully) change in the near future and in fact is being discussed on the list right now.

Since I recently posted about the MNMA (Music Notation Modernization Association), including its mission statement, it seems appropriate to forward on the announcement that the MNMA has disbanded and a new organization has emerged to take its place: The Music Notation Project.

The new mission statement from the website is as follows:

The Music Notation Project seeks to raise awareness of the disadvantages of traditional music notation, to explore alternative music notation systems, and to provide resources for the wider consideration and use of these alternatives. We hope our efforts will help make reading, writing, and playing music more enjoyable and easier to learn.

Today’s letter detailing the announcement hints at what some of the practical differences will be:

While we are still interested in research that evaluates different [notation] systems, we believe we can best further such comparative work through the development of software that can rapidly convert a lot of music into a wide variety of systems.

I think this makes a lot of sense. New notation efforts should take new technology into consideration and benefit from it.

The other practical difference, apart from having a new, nicely designed website, is the name change. “The Music Notation Project” rolls of the tongue much more nicely than “Music Notation Modernization Association”. I was just joking today that the name is a bit “shun”-heavy. Well, they fixed that now. 🙂

This is how the PianoNinja is feeling tonight after suffering a difficult blow:

We had a little setback involving lost code. Ironically, this happened when I was trying to set up version control to guard against this very thing. I’ve posted a message to the user’s list for the IDE that failed to give me a warning before deleting all this naive user’s code, in hopes that similar mistakes by other users can be prevented. Hindsight is 20/20. I should’ve backed it up before trying to…back it up. It would also have been good to have Time Machine set up already, but I hadn’t done that either.

Thankfully, I did still have an older version of the code from before I switched over to the development environment that I’m now using, so I don’t have to start totally all over. And you can be sure that I have already secured that code into version control on a server machine so that I can continue from now on from a solid base.

How bad is it? Well, we were on Video #7. Let’s just say we’ve now reverted back to Video #3. In other words, all the code I wrote in the last two weeks is gone.

Maybe this is a blessing in disguise. Sure, I learned a lesson and I won’t make this mistake again. But the blessing might be that my continued dependency on MIDI files as the game’s underlying format is now that much less alluring. The MIDI crutch has been snatched out from under me. I don’t need to wrest myself from the MIDI code so I can move onto a better way. The code has wrested itself from me…

I was going to add bar lines tonight. Oh well, those can wait.

Before you know it, the ninja will be feeling better than ever.

Okay, this post is just to complete the thought I’ve been exploring over the last couple of posts. I wasn’t up for much heavy thinking tonight, so I decided to just download a free MIDI editor and normalize the durations of the notes in the Chopin Waltz MIDI file so that it had no more staccato releases in the first section of the piece. Now the visual note releases reflect the actual notated durations (except that some Klavarskribo continuation dots are still missing; I haven’t implemented those yet). I wanted to see if this helped make it easier to “see” the beat:

Video #7: Notation-consistent note releases (Quicktime streaming)

I think it works pretty well for this piece of music. The sudden flash of each note release now coincides with the attack of the next note. I think it now looks smooth and rhythmic, which is what I was hoping for.

I haven’t made any progress since yesterday’s report, but I did finally track down our camera. This video shows what I was talking about yesterday: the MIDI Note OFF events are now visible.

Video #6: Note OFF events visualized (Quicktime streaming)

The game isn’t making any sound in this video, because I’m not playing along on the MIDI keyboard. It’s easier to see the note releases when I’m not playing along and adding all the green and red colors. The piece is the same one I’ve been using for the last few demos: Chopin Waltz in E-flat, Opus 18.

The molasses effect of lingering notes is gone, so that’s good. But the note releases are accented too much, in that the suddenness of the notes’ disappearance tends to be the most visually striking movement that’s going on. It’s also dependent on the interpretation of the person who rendered the performance in the MIDI file. My theory is that if performance-dependent note releases are ignored and instead the actual note value is reflected (regardless of whether the note should be played staccato), then the accented note releases will actually help rather than hinder the feeling of the beat, since they’ll most often coincide with the attack of the next note. I’m looking forward to testing my theory out (and then moving on past this academic theorizing).

Today, I tried to enable what I talked about in my last post about PianoNinja. I was able to get the MIDI Note OFF events to be reflected in each note’s visible duration: how long it remains stationary on its piano key before disappearing. (I would have posted a video, but I can’t seem to find the camera right now, and I really need to be getting to bed earlier anyway.) I have a couple of observations:

• It’s much nicer than before: crisp and clean releases, but…
• the effective duration doesn’t necessarily correspond to the actual note value.

A MIDI file contains a rendition of a piece, not (necessarily) the authoritative musical information you’d need to reconstruct a score. Staccato durations, for example, get interpreted as short notes that obscure the actual notated value. I’m coming to terms with what I want PianoNinja to do: display a score (in Klavarskribo notation) that can be relied upon as containing the more-or-less canonical information that makes up the piece. While there might be many and varied MIDI files for the same Chopin Waltz, I don’t want PianoNinja to be subject to those variations.

So while I’m glad that I got the MIDI Note OFF events to be reflected, the associated note-vanishing is still a bit jumpy-looking, since they don’t always coincide with the attack of the following note. Before diving into using MusicXML instead, I might try to see what sorts of MIDI file quantization I could do to stretch each duration out for its full note value. I’m going for the path of least resistance here in keeping this project moving forward—without compromising the steady vision I have for what PianoNinja can be.

As I play around with PianoNinja, I’ve noticed so far that it’s fairly easy to get out of sync with the notes that I’m supposed to be playing. I tend to speed up when playing slowly, for example. (You might have noticed this in the last video I posted). Part of the problem is that I don’t have any strong cues as to where the beat falls. In games like Dance Dance Revolution, there’s a very strong beat—you simply dance to the music that you hear. Ultimately, I think PianoNinja will need auditory cues as well, whether as simple as a metronome sound or as complex as a full accompaniment. (That would make it a lot more fun too.)

But before I add any auditory hints, I want to see how far purely visual cues can get me. Of course, I’ve made the decision to go with Klavarskribo, so the question as to what visual cues to use has largely already been answered for me. (Basically, use solid and dotted bar lines to indicate the primary and secondary beats, respectively.) But what Klavarskribo doesn’t answer is how to display the notes once they reach the point where they’re supposed to be played.

The simplest approach would be to just keep scrolling the manuscript right off the screen, just as if it was a roll of sheet music continuing to unwind. In other words, apart from the scrolling movement, the display would be purely static. You’d know when to play the notes only according to when they cross a given (horizontal) line, but then they’d keep on scrolling off the screen and out of sight. In that case, perhaps the most natural place for that line would be the middle of the screen rather than the top. That way, you’d be able to see the notes come and go rather than immediately scroll off the screen at the top.

I’ve decided to take a more dynamic approach, placing that line at the top of the screen and representing it with a picture of a piano keyboard, so that, for one thing, the relationship between the notation and the piano keyboard is immediately obvious (I hope). The dynamic aspect is that the visible note then freezes and remains stationary on its corresponding piano key for the duration that it’s supposed to be played, while all along the rest of the music continues to scroll upward. Early on, I was experimenting with a grayscale fade-out approach for representing the decay of the note’s sound, but I found that keeping it solid and stationary and then suddenly making it disappear worked nicely—especially when followed immediately by another note in the same hand. The combination of the new note stopping in its tracks and the old note vanishing in the same instant creates a certain visceral perception of the rhythm. At least that’s my suspicion and hope; I haven’t fully put it to the test. Right now, the durations are all hard-coded to the length of one beat, which doesn’t fit well with the Chopin Waltz I’ve been using in my demos. The notes all linger far too long, giving a molasses-like visual effect which doesn’t help you feel the beat at all. So I think I’ll focus next on taking care of those note durations.

With this approach, the most “attack-like” movement that you see is when a note ends, not when it begins. What makes it work is the fact that the disappearance of one note often coincides with the attack of the next. For that reason, it may turn out to work well for some kinds of music, but not so well for others.

But now I’m just speculating. First I’ll get it to work correctly and try several pieces of music with it. If I still find it to be lacking, then maybe I’ll add some kind of “flash” to each note’s attack. I’m hoping that won’t be necessary though. I like the idea of a visually spare interface that still packs a punch—like Klavarskribo itself, and, I hope, like the new PianoNinja logo. 🙂

Tonight I was practicing reading Klavarskribo on my acoustic piano. It’s amazing how much this notation is transforming how I think about the keyboard. All the irregularities of the piano keyboard layout are jumping out at me like they never have before. I’m paying attention to the physical piano keys and their relationship to each other. I’m astonished (and embarrassed to admit) that, after having studied piano since the age of 6, I never consciously noticed (at least as far as I can remember) that four out of five of the black keys are not placed exactly in the middle between their two adjacent white keys. In fact, I unconsciously perceived them the way that Klavarskribo depicts them, spaced equidistantly from their adjacent white keys:

In actuality, they’re spaced out from each other so that the black keys aren’t too close to each other and so there’s not such a big gap between the two groups of black keys:

The difference is subtle, but you can definitely feel it. It’s what accounts for the fact that the minor 3rd starting on A-flat feels a bit bigger than the Major 2nd starting on B-flat. Of course, in my theory-ridden brain, I naturally assume that a 3rd would feel bigger than a 2nd, because it’s a bigger interval. But no, it’s not because it’s a bigger interval, it’s because of the irregularity of the keyboard. In truth, I think the difference in distance feels bigger than it really is, because I’ve been trained to think that it’s a bigger interval. In actuality, they are physically quite similar, and if my unconscious assumption that the black keys were placed equidistant from their adjacent white keys had been true, they would be physically exactly the same.

In Klavarskribo notation, they are physically exactly the same distance from each other:

The above intervals are visually and (at least approximately) physically equivalent. Yet they’re not the same intervals. They are: m3 (minor third), M2 (major second), m3, m3, M2. But if you’re learning Klavarskribo, which makes you very attentive to the keyboard layout, you would recognize these as physically equivalent. They almost seem worth naming (“BWW”, for black-white-white?), at least perhaps as a way of organizing a series of Klavarskribo exercises. After forging the visual-kinesthetic link, you can then start layering on the theory that recognizes that, although these intervals look and feel the same, they are in fact different.

So while Klavarskribo glosses over the slight physical irregularities of the piano keyboard, traditional notation completely abstracts away from the physical characteristics of the keyboard. I’m not saying that’s a bad thing. I just want to clearly see this difference. I do find it terribly odd how unfamiliar I am with the keyboard after so many years of practice and study. And I’m struck how I have to keep saying “physical keys” just to distinguish which meaning of the overloaded term “key” I’m intending. It’s almost like the language of theory is rigged to detract attention from the physicality and irregularities of the instrument. The word “key” tends to mean “tonal center,” and my musically-trained brain keeps gravitating back toward that usage.

In any case, Klavarskribo is a much more raw representation of notes to play on the keyboard, and I’m liking it for that and for the fresh insights it’s giving me.

I’m trying to figure out what file format(s) to support in PianoNinja. Synthesia has gone the route of “blind devotion to MIDI files” and its attendant pitfalls when it comes to notating music. I’ve already gotten a glimpse of these drawbacks now that I’ve tried to add the left-hand/right-hand distinction to PianoNinja. Some MIDI files separate the hands into two different tracks, and some don’t. And there doesn’t seem to be a standard way of doing this. Also, there are other visual cues built into Klavarskribo that I want to include, like bar lines, note beams, rests, continuation dots, etc. These aren’t going to be easy to derive from simplistic MIDI ON and OFF events, especially since the best MIDI files as far as performance goes would tend to be the worst as far as deriving notation goes. That’s my suspicion anyway. I get the impression that there are features of MIDI files that could allow them to provide notational hints, but those are optional and so they can’t be totally relied on.

MusicXML, on the other hand, is designed for representing musical information that can be notated. The biggest disadvantage I see of using MusicXML is that it’s not nearly as widely available as MIDI files are. Where do I go to find MusicXML files anyway? Do I have to purchase them? Do they only exist transiently on their path from Finale to Sibelius or vice versa? If I can get sufficiently past that hurdle, then it seems that I should go with MusicXML.

But there might be some other disadvantages to MusicXML also. Traditional notation requires you to make certain decisions about things like key signatures, whereas key signatures are optional in Klavarskribo (represented by a circle or diamond at the beginning of the piece on the relevant line for major or minor keys, as well as other shapes for different modes IIRC). Are they optional in MusicXML? Or does MusicXML force you to make certain distinctions that Klavarskribo doesn’t require? If MusicXML files were as abundant as MIDI files, I wouldn’t worry so much about this. I’d just take what I need and leave what I don’t need. But if I want to promote the proliferation of PianoNinja music across the Web, would MusicXML raise the bar too high? The purist in me doesn’t want to have to decide whether a note is B-flat or A-sharp in the underlying format when that distinction may not ever appear on the screen in PianoNinja.

So maybe what’s needed is a new “KlavarML” format, along with a converter from MusicXML to KlavarML (using XSLT of course). I presume there are already converters from MIDI to MusicXML (insofar as they’re able to). I don’t want to reinvent the wheel. But I also don’t want to be held back by unnecessary technological limitations. Both MIDI and MusicXML provide too much information. MIDI has lots of performance/interpretation-specific information that’s not relevant to Klavarskribo (although theoretically could be relevant to PianoNinja insofar as the scroll speed could dynamically vary, but I digress). MusicXML makes distinctions that Klavarskribo and PianoNinja do not. And MIDI doesn’t provide enough information.

Whether a “KlavarML” becomes an interchange format or an internal format specific to PianoNinja, I still like the idea. At the very least, the exercise of designing it would help clarify the whole domain of what it is I need to represent in PianoNinja. And it would also give me another opportunity to use RELAX NG. 🙂

Whereas in the last video all the note stems pointed to the right (which made it difficult to tell which hand was supposed to play which notes), now I’ve associated MIDI events in one track with the left hand, and the other track in the right hand. For those of you who aren’t familiar with Klavarskribo (which is probably 99% of the population), if a stem points to the left, then that means the note is meant to be played with the left hand. If it points to the right, use the right hand.

PianoNinja Video #5: both hands (Quicktime streaming)

My 7-year-old son was holding the camera, while I was using both hands to play. He was trying his best to hold it still. 🙂

Tonight I got some scrolling notes to appear on the screen in response to MIDI events being played back from a MIDI file. Observe:

There are a number of deficiencies still:

• no bar lines (that aren’t irrelevant and hard-coded still)
• no note durations (also hard-coded)
• no right-hand/left-hand distinction (all hard-coded to the right)
• stems are too short in some cases, erroneously breaking the chord up
• no beams for grouping related notes in a line

Despite these deficiencies, I’m really stoked. I’m starting to get a sense of what it will be like to use this game and to practice sight-reading with it (using Klavarskribo notation, of course). My vision is starting to be realized!

Earlier this month, I decided to come up with a name for the Klavarskribo video game I’m working on, so I wouldn’t have to keep calling it the “Klavarskribo game”. I was planning on making the name public when I had a first version ready to download. But last night I came up with the coolest logo for it that I just couldn’t wait to share it. (You’ll have to be the judge; perhaps I’m just sleep-deprived.)

I’m no graphic designer, so I didn’t think I’d actually come close to anything I’d be happy with. I just thought I’d sketch out some concepts. Here’s what I started with:

I did a quick Google search for drawing programs for OS X and downloaded a trial copy of EazyDraw. Within an hour, I was liking how things were going, so I purchased a license. I added some finishing touches today, and here’s the final result:

Why “Piano Ninja”? Well, for one thing, ninjas are cool. My 7-year-old has taken a particular liking to them lately, so I already have ninjas on the brain. I wanted to juxtapose the word “piano” with something indisputably cool (ninjas), since, let’s face it, “practicing piano” and “piano lessons” don’t traditionally evoke the same sense of enthrallment someone gets when absorbed in a video game (such as Guitar Hero). Also, I already mentioned that I don’t plan to knock on many piano teachers’ doors anytime soon (I’m no glutton for punishment), so I’m not terribly concerned with making the name sound “respectable” to the music education world. Finally, I like the stealth component that’s built into the name.

Now I’ve got no excuse but to get moving on this game (heh, as if not having a logo is what was holding me back). Anyway, I’ll continue to chronicle my progress as I’ve been doing so far.

I discovered and joined the Google group for the MNMA. Now I’m reading lots of interesting discussions about alternative notations, 7-5 keyboards (traditional piano keyboard: 7 white, 5 black) vs. 6-6 keyboards (like Janko and Chromatone). One thing I really like about the general feel of these discussions is the openness with which people greet each other’s ideas. Rather than clamoring to promote their pet notation systems at the expense of others, they generally seem to embrace new ideas as contributing to progress. They seem to embody their declared purpose well:

The MNMA is an international nonprofit organization dedicated to exploring ways to make reading and playing music easier to learn and enjoy. This is our forum for open discussion of music notation improvement, alternative music notations, and related topics.

One thing I think is missing in the discussions is an explicit emphasis on use cases. Klavarskribo and some of the other ANs (which in the MNMA forum is shorthand for “alternative notation”) as well as TN (“traditional notation”) are each what I would call a general-purpose music notation system: a single system designed to support pretty much any piece of Western music, and any activity relating to that piece of music. But I wouldn’t assume that the same notation would be equally well-suited to the very different activities of sight-reading, learning a piece for the first time, and analyzing a piece, to name a few. Similarly, I wouldn’t assume that a given notation would serve equally well for all pieces of music. In one of the MNMA forum discussions, someone mentioned that:

One person on the LilyPond list wanted to see Bartók in a chromatic
staff in order to see the symmetry. With just accidentals, and no
vertical change of position, the symmetry is hidden, just as TN hides
the symmetry.

Each piece has a logic of its own. A one-size-fits-all approach to notation is guaranteed to obscure much of that logic. The extent to which the composer’s structural intentions are clearly revealed will be haphazard if the notation is designed or chosen independently of the piece being represented.

So along with “use cases” and “refactoring”, I’d like to borrow another term from software engineering: “domain-specific languages”. But let’s modify that slightly: PSLs (piece-specific languages). And PSLs would have a leg up on DSLs, because we wouldn’t necessarily have to make them dumb enough for a computer to understand.

Tonight I read this article, by James Wierzbicki, about the Music Notation Modernization Association (MNMA). It eloquently reviews several common reasons that some people wish to update/reform/replace (or simply add alternatives to) traditional music notation. It includes mention of Klavarskribo. It also reviews the 1000-year-old history in which music notation evolved in ad hoc ways, leading to the complex, baroque notation that we have today. I was totally with him until I reached the last several paragraphs, in which he accuses reformers of being naive and also claims that new notation systems, “while they correct a particular problem or two, at the same time…create a thousand more problems that their champions apparently find unimportant.”

Up until that point, the article seemed to be leading to the conclusion that alternative notations should be welcome, given all the trouble that beginners and advanced musicians alike have had with traditional notation. So his conclusion caught me off guard. And it underscores why I’m not interested in trying to shove Klavarskribo or a Klavarskribo video game down the throats of music teachers. Even when the problems with traditional notation are acknowledged and the logic behind new notation proposals is clearly understood, the conclusion is often to dismiss, ignore, or even decry such proposals as naive, dangerous, etc.

His last paragraph summarizes his position well:

Speaking for the establishment, I think our opposition to sweeping reforms is quite innocent. Most of us, because we have spent our lives with traditional music notation and because we are aware not just of its limitations but of its possibilities, are satisfied with the status quo. The existing means of notating music is not perfect, and we know this. Still, Guido’s system ain’t exactly broke, so why fix it?

I’m not concerned with throwing away 1000 years of notation history. I’m just interested in promoting an alternative which would allow a greater number and variety of people to make music from reading a score without having to first study theory (which is what traditional notation effectively requires). You won’t have to be part of the “establishment” to start reading music. And the establishment won’t have to worry about you either, since you’re not reforming anything. You’re just playing the piano. Peaceful coexistence is possible.

That’s what I’m choosing to pay attention to for now: enabling people to have fun, play another engaging rhythm game, and learn some piano in the process. If this leads to music education reform, then it won’t be because that’s what I set out to do. It will be because people demand it, having experienced another way.

I don’t have much to update tonight about my Klavarskribo game progress. I’m currently trying to find a free Java profiler that will help me isolate whatever code inefficiencies are causing the slight delay between pressed piano keys and visible feedback on the screen. Yes, I’m using Java for this project. Java wasn’t my first choice, but since I have some experience with it and since it has built-in MIDI support and books about game development with starter code to work from, I found that it was my fastest way to get started. Before that, I was contemplating using languages that I’d rather learn more about, like Haskell and Q. But for me right now, the elegance of those languages would be distracting. My current focus is on getting the thing to work, not writing beautiful code. I’m not sure if you could call what I have “working” yet, but I have definitely written–rather, splatted–plenty of non-beautiful code onto the screen already. So I’m right on track.

My MIDI-to-USB adapter arrived via UPS today, so I hooked it up to the Roland RD-600 that I’m borrowing from my wonderful neighbors. I’m pleased to see that it works right out of the box and I only needed to make one small modification to my code to make (what’s implemented of) the video game to work. (Whereas previously it was only expecting MIDI note off events to appear as “note on” with volume 0, now it will handle explicit “note off” events as well.)

(Please forgive the low recording quality. I was using one hand to hold the camera and one hand to play the keyboard.) As you can see, there’s a fairly significant delay between the sound (which is pretty immediate) of me striking a key and the visual (green or red) note response that appears on the screen. This is something I have to work on before the game will be close to release-worthy.

Now that I have a functioning MIDI keyboard, I’m really motivated to get some real music in there (instead of these hard-coded notes that rise up the screen).

Over Christmas break, I got inspired to work on the Klavarskribo game some more. The video below shows the color coding I mentioned in my last post. When a currently-played piano key overlaps with a supposed-to-be-played piano key, the note is green for the duration that it’s supposed to be played. If you play a wrong note or if you hold the note for longer than it’s supposed to be played, it will be red. Any supposed-to-be-played notes that you don’t play will simply be black, until you hit them and then they’ll turn green. So the object of the game, at least as currently realized, is to make things as green as possible.

You’ll notice that the notes rising on the screen (which include an ascending chromatic scale and some random chords) have nothing to do with the live MIDI input. It’s as if the user is ignoring the notes on the screen and instead playing a Chopin waltz. So you end up seeing mostly red notes with a couple of green notes where the two happen to line up. That’s because I don’t yet have an actual MIDI keyboard hooked up. I’m waiting for a MIDI-to-USB adapter to come in the mail on Monday…