• “Mastery” (Part 1, Part 2, and Part 3)
• Reasoning with a 3-year-old
• Mimsy Sadofsky on play and talking
• Appreciating your own kids

I’ll probably still blog here on miscellaneous topics on an occasional basis (as always), so feel free to subscribe to both.

He puts forward lack of positive evidence as his principal reason for not believing that God exists. Paraphrasing Bertrand Russell, he says, “there’s no more reason to believe in the Christian God than in the Greek gods.” I think this is a silly assertion. Nobody believes in the Greek gods today. However, many millions of people do believe in the Christian God today. He may not think that’s a good enough reason to believe in God, but it’s a big jump to say there’s “no evidence”. If he’s talking scientific evidence, then I grant him the argument. Scientific evidence is a very narrow sort of evidence, as science is a very narrow sort of inquiry. But the continuing faith of millions over thousands of years does constitute some sort of evidence.

Later in the interview, he admits that people do have a sort of “cosmic loneliness”, or angst. He sees this as an explanation for why people have such a need for believing in God. The belief appears to satisfy their deep need for connection. This is another sort of evidence. You can use it to either explain people’s need to believe despite God’s non-existence, or you can view it as another sort of evidence for God—a being which, when believed in, “satisfies a deep craving in the human soul”, as McGinn puts it.

McGinn is most persuasive, I think, when he brings up the problem of evil. This should be truly challenging to any Christian or anyone who believes in the existence of a good, all-powerful God. Why would a good, all-powerful God let evil things happen in the world? McGinn notes the standard, ultimately unsatisifying explanation offered by theologians: God gave us free will, and we’re the ones that mess it up. Then what about natural disasters? Ultimately, the problem of evil is a real problem for faith. One of my beliefs as a Christian is that whereas God is all-knowing, we are not. And we’re not particularly meant to be. There are things we don’t understand and won’t ever understand in this life. Atrocities such as holocausts happen. There is a profound potential for evil in the human heart. These are things we have to contend with, even if we can’t fully explain them. If you’re going to believe in a religion, make sure it’s one that acknowledges and contends with the reality of suffering in the world and evil in the human heart—even if you were born into a free, wealthy society such as America where we are protected from much of the world’s suffering.

I have friends, family members, and colleagues who are atheists, and I want to better understand their point of view. I also want to find ways to address my doubts and to bolster my own faith in the face of unbelief. Despite my natural affinity for philosophy and philosophical arguments, I don’t put my hope in them as a primary way to grow closer to God (which is a primary goal of mine). They do play a minor role though; they fit in somewhere. Otherwise, I wouldn’t feel compelled to write about this topic. Just know that I haven’t even begun to expound on why I do believe, and I can’t necessarily explain all the reasons why I’m compelled to believe. (For one thing, I believe God had a large role in my choosing to believe and continue to believe, and that’s hopelessly circular from a philosophical perspective.)

This is just one example of a .NET function you can access as an extension function in XSLT 2.0, so a more general-purpose treatment of .NET extension functions might be more useful. (I defer to “Writing extension functions for .NET” for that.) But if you’re like me, you spend most of your coding time within the safe, comfy confines of pure XSLT. And you do very little .NET development. So to ensure your continued comfort, here’s how you can generate a GUID in Saxon.NET (relevant parts highlighted):

<xsl:stylesheet version="2.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:guid="clitype:System.Guid?partialname=mscorlib"
  exclude-result-prefixes="guid">

  <xsl:output indent="yes"/>

  <xsl:template match="/">
    <guids>
      <guid>
        <xsl:value-of select="guid:NewGuid()"/>
      </guid>
      <guid>
        <xsl:value-of select="guid:NewGuid()"/>
      </guid>
      <guid>
        <xsl:value-of select="guid:NewGuid()"/>
      </guid>
    </guids>
  </xsl:template>

</xsl:stylesheet>

Here’s an example result from applying this stylesheet (to any input document):

<guids>
   <guid>6dbd3a72-ad74-429d-97ca-3056e8940813</guid>
   <guid>cea97da4-9de5-4fb5-a35e-ba04a0dee906</guid>
   <guid>41c89105-6cf7-4fd6-b17a-ed04235a4804</guid>
</guids>

All you do is call the .NET platform’s System.Guid.NewGuid() method as an extension function. The function’s namespace URI identifies for Saxon what assembly and object class you’re interested in (System.Guid in this case).

Thanks to M. David Peterson: I found this usage buried in a code example in his lucidly-titled blog post: if ((OOP + FP + AOP) == XSLT 2.0) then ‘Composable Language’ else ‘Try Again’.

• 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.

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.

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.

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).

• 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.

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.

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.