Evan Lenz

Back in college, I majored in piano performance and have mostly been out of practice since then. I tell people that I’ve always had a love/hate relationship with the piano. Recently I picked up a Brahms Intermezzo I learned years ago, so I could play it at the memorial service for my wife’s grandmother. This has got me back to wanting to learn more music again. But I always run into the same mental difficulties when learning music. I long for a more efficient way to load musical information into my brain/body. Deciphering traditional music notation has never been fun for me. Some cases are worse than others. Atonal music is particularly frustrating to learn from the traditional notation.

Consider the first phrase of #2 from Ned Rorem’s Eight Etudes for Piano.

These chords look like a bunch of triads, but that completely obscures what’s really going on. They’re actually very dense chords, and it would be folly to try to play triads with each hand. I got so frustrated after spending a little time trying to (re-)learn this piece, so I decided I needed some way to capture the information after decoding what was written, rather than traversing it repeatedly and hoping some of it would stick, when in reality it would keep falling right out of my brain because I had no way to easily read it.

Short of having someone play it for me repeatedly, so I could watch the correct keys being depressed (or short of owning a Disklavier which could also do that for me), I fired up Vim and started making some ASCII art:

| | |   | |   | | |   | |   | | |
 _ _ _ _ _ o o o _ o o o _ _ _ _


| | |   | |   | | #   | |   | | |
 _ _ _ _ o o o _ o _ o _ _ _ _ _


| | |   # #   | # |   | |   | | |
 _ _ _ _ _ o _ _ o o _ _ _ _ _ _


| | |   | |   | | |   | |   | | |
 _ _ _ _ _ o o o _ o o o _ _ _ _

The rhythm is easy enough to read with traditional notation, so I ignored that part. I just wanted to capture the notes of the chords. The vertical bars provide a template representing the black-key landscape of the keyboard. The circles are white key notes, the # signs are black key notes. After seeing this on the screen, it reminded me of Klavarskribo (Esperanto for “keyboard writing”), which was invented in 1931. I’ve never investigated Klavarskribo very closely. For some reason, I never got inspired by it before today. But now I have this feeling that I’m going to become the next Klavarskribo evangelist. It’s like DDR notation for piano. (Why not?)

Thanks to the fantastic and free KlavarScript software, I mocked up the corresponding phrase (including rhythm this time) in Klavarskribo:

Learning Klavarskribo will be challenging, but I have this feeling that after just a little effort the floodgates will open for me. Most of what I’ll need to do is un-learn what I already know about traditional notation. I see an analogy with imperative programmers trying to learn Haskell (or XSLT) for the first time. They’re trying to overcome “being brain-damaged by years of imperative programming” (their words, not mine). Thankfully, I didn’t have that obstacle in the programming world, because XSLT is where I started. But with music notation, I indeed will need to overcome years of brain damage, not to mention psychological distress, inflicted by traditional notation.

I thought I’d post a brief answer to the question I raised in my last post, which was “is there an analogous higher-order function [like foldr] for recursion on numbers?”

As I pointed out, you can define product using foldr, like this:

product = foldr (*) 1

What I wanted is another function, say foldrNum, that would allow me to define factorial using the same idea:

factorial = foldrNum (*) 1

As it turns out, all I need to do is make some slight modifications to the foldr definition, which looks like this:

foldr            :: (a -> b -> b) -> b -> [a] -> b
foldr op v []     = v
foldr op v (x:xs) = op x (foldr op v xs)

I’ll keep foldrNum general enough so that, like foldr, it can return a value of any type (b), but unlike foldr, which can process a list of any type (a), I think it’s essential to the idea of foldrNum that it only operate on a non-negative integer, which is what the recursion is based on. First, I’ll show the definition of foldrNum I came up with. Then I’ll compare it line-by-line with foldr so that we can see exactly what’s the same and what’s different.

Here’s foldrNum:

foldrNum           :: (Int -> b -> b) -> b -> Int -> b
foldrNum op v 0     = v
foldrNum op v (n+1) = op (n+1) (foldrNum op v n)

The similarities are obvious, but I like to make things as obvious as possible. First, the types of each function:

foldr               :: (a   -> b -> b) -> b -> [a] -> b
foldrNum            :: (Int -> b -> b) -> b -> Int -> b

Now, the base case:

foldr    op v []     = v
foldrNum op v 0      = v

Finally, the recursive case:

foldr    op v (x:xs) = op x     (foldr    op v xs)
foldrNum op v (n+1)  = op (n+1) (foldrNum op v n)

The natural question arising from this is “How do I generalize foldr and foldrNum, since they’re so much alike?” Joshua Ball anticipated that question in his comment on my last post, although I confess I haven’t fully wrapped my head around his solution yet.

I think this is enough for today. So many possible directions to go in. I must content myself with one small piece at a time. 🙂

I’m writing this post as a way of moving myself forward at least one notch through Graham Hutton’s Programming in Haskell, which I’ve been very slowly, occasionally working through. I’m in the middle of chapter 7 right now.

The thing that slows me down (apart from having 3 kids at home including a baby) is that I’m distracted by the learning process itself. I don’t want to too easily forget the false or imperfect theories that I form along the way. A teacher’s job is to help bridge the gap between imperfect models in the student’s mind and models that are more useful and effective. But the only way they can do that is to be familiar with such inaccurate models, as well as to value them as important stages of the student’s learning (rather than reject them out of hand as is the modus operandi of schools today, but I digress). I may want to teach this stuff some day, and this is my only chance to observe the learning process first-hand, at least as a beginner. I need to keep a log of my learning, or at least parts of it, in order to keep me moving forward with the assurance that my intermediate stages of learning will not be forgotten forever.

Quick disclaimer: This post is not the first of a series of Haskell posts, at least not any planned series. I hereby give myself permission to not post on Haskell ever again, or for that matter, to drop it in favor of learning something else (although given how much I keep getting drawn back to it, I’m pretty sure that won’t happen).

Recursion patterns

In chapter 6 (on recursion), I noticed there are basically two things you could base recursion off of, or two things to “recurse” on:

• a list, or
• an integer

Recursion on an integer

The basic pattern for recursion on an integer is evident in the definition of the factorial function:

factorial 0     = 1
factorial (n+1) = (n+1) * factorial n

The factorial of 0 is just 1 (the identity for multiplication). The factorial of a positive integer (represented by (n+1)) is that integer ((n+1)) multiplied by the factorial of one less than that integer (n). The function is invoked recursively until the numbers run out and the termination case is reached (an argument of 0).

Recursion on a list

The basic pattern for recursion over a list is evident in the definition for the product function:

product []     = 1
product (n:ns) = n * product ns

The product of an empty list is just 1 (again, the identity for multiplication). The product of a non-empty list (represented by (n:ns)) is the result of multiplying the head of the list (n) times the product of the tail of the list (ns). The function is invoked recursively until the list runs out and the termination case is reached (an empty-list argument).

Capturing the list-recursion pattern

I’m only partly through chapter 7 (on higher-order functions), but I’ve now been introduced to the foldr library function, which captures the pattern evident in the product function, which uses recursion over a list. Here it is:

f []     = v
f (x:xs) = x ⊕ f xs

The v stands for some base value (which was 1 in the product function). The circled-plus symbol (⊕) stands for some operator (which was * in the product function). The foldr function takes those two variables (a base value and an operator) and automatically constructs a function for you that does the above. So you can now define product more succinctly (and without using explicit recursion):

product ns = foldr (*) 1 ns

Or even more succinctly, and thanks to Haskell’s function currying:

product = foldr (*) 1

What about capturing the number recursion pattern?

The open question in my mind is: is there an analogous higher-order function for recursion on numbers?

What wasn’t explicitly mentioned in the book is the idea that an integer can be thought of as representing a list of numbers, starting at that number and counting down to 1. If that’s the case, then I could just use foldr for recursion on a number, provided that I first turn that number into a list of numbers counting down to 1.

Using that idea, here’s another way to define factorial:

factorial n = foldr (*) 1 [n,(n-1)..1]

Of course, in the case of multiplication, the order of the list of arguments doesn’t matter, so the list doesn’t have to count down. It could start at 1 and count up to the integer instead:

factorial n = foldr (*) 1 [1..n]

Anyway, that’s where I’m at with these half-baked observations. I’m sure I’ll find better or more appropriate abstractions as well as more interesting insights. I’ll be able to look back at this post and say “Oh, what you want is the ____ function!”

A Vim/Dvorak tutorial. First, QWERTY is designed to slow typists down (so early typewriters wouldn’t jam). Then, Vi was designed to make keystroke editing commands easy on QWERTY keyboards. Meanwhile, the Dvorak keyboard was designed to enable faster typing and prevent carpal tunnel.

How bizarre then to see a tutorial for Vi keystrokes on a Dvorak keyboard:

Just look at where those up/down/left/right arrow keys are.

I have to wonder if this person really uses Vi. Maybe the joke’s on me. 🙂

The original one it’s based on is quite cool though.

It’s a frightful thing, the power that music can have on my emotions. It’s a frightful thing, my emotions. When reason reigns, and feeling has no reason, then feeling only threatens. Feeling is responsible for the arbitrary associations I find in my neurology. A smell, a sound, a rush of memory. The object, for me, is forever tainted. And for what reason? Of course I do not want to subject myself to such randomness. I do not indulge. I love music. Therefore I do not listen to it. Indulgence is mindless. I have no control over the result. What new links are going to get created inside me that I had no say in allowing? Experience is a demon, always threatening to possess me. So I must stay on guard. Is it any wonder I don’t remember so much of my childhood? I did not allow it to possess me like a demon. I cut it short. Masterfully.

I must stay on guard, because it’s a powerful beast. Atrophied, yet still it heaves with terrible strength. If I’m careful, I can keep the noise loud enough to drown out its breathing. When it does come through–and I feel the disgusting feeling of nostalgia, the heart-breaking feeling of nostalgia–I’m vindicated in my resolve. If I can’t have the experience back, then why flirt with it? Do I enjoy pain? Shall I enjoy grief? And so I pretend that emotions are scarce. Feeling is a sacred, pure thing reserved for lofty notions. I’ve always known better than those who lose themselves at rock concerts.

Priscilla Walmsley was kind enough to point me to a post from Jim Garrison on comp.text.xml regarding XSLT 1.0 Pocket Reference, which I poured my heart and soul into last year. This was actually the first feedback I’ve gotten from anyone who has used the book. Needless to say, it made my day:

First, a big thank you to Evan Lenz for the O’Reilly XSLT 1.0 Pocket Reference. This is an amazing feat of distilling all you really need to know about XSL into 170 pocket-sized pages. What’s more amazing is that an experienced developer with little prior XML/XSL experience can actually learn enough from this little gem to write competent XSL.

A reference manual AND quality tutorial in 1/20th the space (and dead trees) of most tech books these days. I’ve recommended this to several of my colleagues who had to get up to speed on XSL for a new project, and the reaction from them is the same as mine…. This was EXACTLY what I needed.

So, Evan, when is the version for XSL 2.0 coming out?

As I already told Jim, such is not in the works right now, but if it were, I hope he wouldn’t hold me to keeping it within 170 pages again!

I was reading in Chapter 6 of Practical Common Lisp about dynamic (a.k.a. “special”) variables and it hit me that this is something that I have longed for in XSLT.

I generally favor using template rules, and hence xsl:apply-templates, over xsl:for-each whenever possible. But sometimes it’s a pain—particularly when you have to pass parameters around.

An example using <xsl:for-each>

Take this contrived piece of code, for example:

<xsl:template match="foo">
  <xsl:variable name="x" select="string(@x)"/>
  <xsl:variable name="y" select="string(@y)"/>
  <xsl:for-each select="document('some-doc.xml')//bar">
    <my-element x="{$x}">
      <xsl:for-each select="document('another-doc.xml')//bat">
        <another-element y="{$y}"/>
      </xsl:for-each>
    </my-element>
  </xsl:for-each>
</xsl:template>

Okay, not so bad. But it’s inflexible.

The template rule version

If I wanted to convert this to a solution using template rules, I’d end up with this monstrosity:

<xsl:template match="foo">
  <xsl:variable name="x" select="string(@x)"/>
  <xsl:variable name="y" select="string(@y)"/>
  <xsl:apply-templates select="document('some-doc.xml')//bar">
    <xsl:with-param name="x" select="$x"/>
    <xsl:with-param name="y" select="$y"/>
  </xsl:apply-templates>
</xsl:template>

<xsl:template match="bar">
  <xsl:param name="x"/>
  <xsl:param name="y"/>
  <my-element x="{$x}">
    <xsl:apply-templates select="document('another-doc.xml')//bat">
      <xsl:with-param name="x" select="$x"/>
      <xsl:with-param name="y" select="$y"/>
    </xsl:apply-templates>
  </my-element>
</xsl:template>

<xsl:template match="bat">
  <xsl:param name="x"/>
  <xsl:param name="y"/>
  <another-element y="{$y}"/>
</xsl:template>

UGH! It’s bad enough to have to pass parameters around. Add in XSLT’s syntax for parameter-passing and it becomes excruciating. So… in this case, the solution using <xsl:for-each> has to be preferred, because the variables stay within lexical scope and require no parameter-passing. The only reason to go with template rules is when you really do need the flexibility afforded by the latter solution (e.g. enabling a template rule to be overridden, etc.).

Using a global variable is often the solution (and a perfectly acceptable one), but in this case, the values may vary for each <foo> element that is processed, and I don’t know upfront how many <foo> elements there will be. So that won’t work here.

Enter dynamic variables. As explained in the aforementioned chapter on Lisp, a dynamic variable is a global variable that can have multiple bindings. You have the option of shadowing it in a given lexical context and—here’s the kicker—for the full extent of any calls you make to other functions. For XSLT, just replace “functions” with “templates”.

The fanciful template rule version

XSLT doesn’t have such a thing, but if it did, it might look something like this:

<xsl:variable name="x" special="yes"/> <!-- made-up "special" attribute -->
<xsl:variable name="y" special="yes"/>

<xsl:template match="foo">
  <xsl:let name="x" select="string(@x)"> <!-- made-up "let" element -->
    <xsl:let name="y" select="string(@y)">
      <xsl:apply-templates select="document('some-doc.xml')//bar"/>
    </xsl:let>
  </xsl:let>
</xsl:template>

<xsl:template match="bar">
  <my-element x="{$x}">
    <xsl:apply-templates select="document('another-doc.xml')//bat"/>
  </my-element/>
</xsl:template>

<xsl:template match="bat">
  <another-element y="{$y}"/>
</xsl:template>

To me, this would be ideal. No parameter-passing required.

XSLT 2.0 offers a very good compromise

XSLT 2.0 introduces what are called “tunnel parameters”. I’ve known about these for a while, but my new acquaintance with dynamic variables in Lisp is helping me understand where these fall in the spectrum of programming language features. If the above example shows what a “global dynamic variable” looks like, then tunnel parameters represent what you would call a “local dynamic variable”. So here’s the bona fide XSLT 2.0 version of the above, without resorting to any made-up syntax:

<xsl:template match="foo">
  <xsl:apply-templates select="document('some-doc.xml')//bar">
    <xsl:with-param name="x" select="string(@x)" tunnel="yes"/>
    <xsl:with-param name="y" select="string(@y)" tunnel="yes"/>
  </xsl:apply-templates>
</xsl:template>

<xsl:template match="bar">
  <xsl:param name="x" tunnel="yes"/>
  <my-element x="{$x}">
    <xsl:apply-templates select="document('another-doc.xml')//bat"/>
  </my-element/>
</xsl:template>

<xsl:template match="bat">
  <xsl:param name="y" tunnel="yes"/>
  <another-element y="{$y}"/>
</xsl:template>

With tunnel parameters, you don’t have to declare a parameter unless you need access to it. And the only time you have to explicitly pass the parameters is when you initialize them. After that, you can just trust that they will be there for you when you do need them, later on down the call stack.

Since this is just a simple example (with only two template rules being invoked), it doesn’t do justice to how helpful tunnel parameters actually are. Imagine 10 more template rules that get invoked between the first and last one. Most of those won’t require any xsl:param declarations. In other words, the final example above is much better than it looks. Conversely, the first template rule example above (the XSLT 1.0 solution) is much, much worse than it looks. Imagine having to type out <xsl:param>or <xsl:with-param> 40 times in a row. That’s essentially what you’d have to do.

Conclusion

I may actually write some programs in Lisp at some point, but so far the insights I’m getting into XSLT alone are worth the effort of learning it.

Wouldn’t it be nice to be able to interact with Lisp sub-expressions? I should be able to, say, hover over a sub-expression (having perhaps set some default input data) and see the dynamic result of that sub-expression. That would make it easier to understand expressions, debug them, etc. Maybe the REPL is all that’s really necesary and I just haven’t learned it well enough yet. But it would be really handy to interactively explore the list transformations that happen as an expression (that I’ve already typed out) is composed. I couldn’t imagine a faster way to explore it than by hovering over sub-expressions and seeing the result in another window.

Has anyone built anything like this?

From the same Lisp tutorial I’m reading:

This “back-quoting” technique is a great feature in Lisp- it lets us write code that looks just like the data it creates. This happens frequently with code written in a functional style: By building functions that look like the data they create, we can make our code easier to understand and also build for longevity: As long as the data doesn’t change, the functions will probably not need to be refactored or otherwise changed, since they mirror the data so closely. Imagine how you’d write a function like this in VB or C: You would probably chop the path into pieces, then append the text snippets and the pieces together again- A more haphazard process that “looks” totally different from the data that is created and probably less likely to have longevity.

This is one of the things I’ve always liked about XSLT. The template rules directly show the XML that is being created. Attribute value templates (AVTs) are helpful in this regard too. In fact, I try to use them whenever possible. I try to avoid using xsl:attribute (unless there’s no other way to do it, i.e. when the attribute’s presence is conditional). For example, when you have to use an instruction to get an attribute’s value, this may seem the most natural approach:

<para>
  <xsl:attribute name="lang">
    <xsl:apply-templates mode="get-lang-value" select="."/>
  </xsl:attribute>
  ...
</para>

But I far prefer this approach even if it does take a few more characters:

<xsl:variable name="lang">
  <xsl:apply-templates mode="get-lang-value" select="."/>
</xsl:variable>
<para lang="{$lang}">
  ...
</para>

That way, when reading the code to figure out what it does, your eye can just skip by the variable definition (it’s just a variable; it doesn’t do anything). After that, it’s easy to see what we’re creating. The first example requires you to look more closely and to think about it for a second, ugh.

Now this is just a small version of a much bigger problem with understanding XSLT stylesheets, especially ones that use a lot of template rules. They can be so dynamic that you absolutely must see an example source document (input data) to understand what the stylesheet does. Integrating dynamic execution profiles into development via multiple code views and software visualization—those are some of my research interests…

I took a detour from Seibel’s book to try out this neat little Head First-like Lisp tutorial.

In it, there’s some sample data:

(setf *map* '((living-room (you are in the living-room of a wizards house. there is a wizard snoring loudly on the couch.)
                           (west door garden)  
                           (upstairs stairway attic))
              (garden (you are in a beautiful garden. there is a well in front of you.)
                      (east door living-room))
              (attic (you are in the attic of the wizards house. there is a giant welding torch in the corner.)
                     (downstairs stairway living-room))))

And a function for accessing part of that data:

(defun describe-location (location map)
  (second (assoc location map)))

The second function grabs the second item in the list returned by (assoc location map). What bothers me initially is that the order in which I have to write this seems to be the reverse of the order in which I would think through the problem. For example, if I wanted to get the description of the living room, I would think “First, get the *map*. Then, look inside it for the living room. Finally, grab the second item in the living-room list.” This is the way it works in XPath. If the sample data was XML, then an XPath expression for getting the living room description might look like this:

/map/*[@name=$location]/*[2]

Start with the map, then get location, then get the second item inside that. (Also, one nice thing about XPath 2.0 is that path expressions are generalized for function application. You can write get-map()/get-location()/get-second-item(), which works the same way in this case because each step returns a 1-item list.)

Anyway, I’m sure there’s probably another way to write such Lisp expressions that doesn’t require me to think backwards and—worse yet—keep all the steps in my head at once. Maybe an object-oriented approach is all that’s needed a la map.getLocation().getSecond() (like in Java). Short of that, I could always bind temporary results to variables and build up the function calls from that. But I really don’t like being forced to create variables just so I can write the code in the order that seems natural.

Maybe I just need to reverse my thinking. Maybe this has something to do with what Paul Graham refers to as “bottom-up programming”. I don’t know.

Speaking of the Head First series, Kathy Sierra just posted “The Clueless Manifesto”. In the spirit of that, I intend to ask even more dumb questions as I continue to learn Lisp. I may want to teach this stuff some day, and this will be a record of what it was like for me when I was a beginner.

In bed this morning, I was contemplating all I learned about Lisp last night. XSLT’s most obvious analog to Lisp macros is its ability to generate stylesheet code, since XSLT is in XML syntax.

But if data is really code, then XSLT template rules are also like macro definitions. An element in the source document is processed and thereby expanded, causing the code in the body of the corresponding template rule to be executed.

At one level, template rules seem more powerful than Lisp macros. A macro is defined by a name and resolved via name-lookup, whereas a template rule is defined by a pattern and resolved via pattern-matching. I don’t think I’ve encountered this level of indirection yet in my two days of learning Lisp. I’m curious what the best analog to this pattern-based function resolution is in Lisp. Maybe the best analog is to be found in particular Lisp functions, such as remove-if-not. Perhaps XSLT’s core processing model is like just another Lisp function.

An obvious difference is that Lisp macros are expanded recursively, whereas template rules are just applied once. I’ve wanted a way to apply them recursively sometimes (well, certain template rules in my stylesheet if not all of them). This isn’t built in to XSLT. Either you have to store a temporary result in a variable and then process the results again, or you have to define a pipeline process outside of XSLT to invoke the XSLT processor. I’ve contemplated how a more automatic recursive application of template rules might look or might be built into an XSLT-like language.

Anytime you learn something new, you’re going to compare it to what you already know. So far, it seems like having an XSLT background is going to be helpful in my learning of Lisp.

Got Aquamacs, Allegro CL, and SLIME up and running on my iMac at home. I can’t believe I’ve already been using Vim for 5 years now. Emacs is certainly another world. But I am motivated one way or another to learn Lisp, and learning Emacs seems to go hand in hand with that. So far, Viper mode is my friend. But I’ve already gone so far as to swap my Capslock and Control keys, as recommended in “Effective Emacs”.

So far, I’ve worked through chapter 3 of Peter Seibel’s book and am now reading chapter 4. That macros are a way of life in Lisp is exciting. I’ve gotten a glimpse of their power with XSLT, but I’m looking forward to taking it to the next level.

Below is a smattering of quotes from some passages in Gadamer’s Truth and Method that are serving as part of the inspiration for my final project in DXARTS 202.

Experience is not wordless to begin with, subsequently becoming an object of reflection by being named, by being subsumed under the unversality fo the word. Rather, experience of itself seeks and finds words that express it. We seek the right word–i.e., the word that really belongs to the thing–so that in it the thing comes into language. Even if we keep in mind that this does not imply any simple copying, the word still belongs to the thing insofar as a word is not a sign coordinated to the thing ex post facto…

There is, however, an idea that is not Greek which does more justice to the being of language, and so prevented the forgetfulness of language in Western thought from being complete. This is the Christian idea of incarnation…

For, in contrast to the Greek logos, the word is pure event…

…that which emerges and externalizes itself in utterance is always already a word…

The inner word remains related to its possible utterance…

…it is the act of knowledge itself.

The meaning of the word cannot be detached from the event of proclamation…

This morning’s reading is for my class. It’s from a book called Visual Intelligence: How We Create What We See. One of the things it talks about is how our brain constructs lines from the light that enters our eyes:

And that is what you do each time you see a line. You construct it from receptor responses. This is not so easy as you might think. Just ask researchers in computer vision. They have worked on “edge detection” or “line finding,” an apparently simple problem, for decades. They have made progress, but their current solutions require much computation–on the order of tens of millions of multiplications and additions just to construct lines in one small image. Even so, their performance is no match to yours.

Constructing a line from what clearly looks like a line seems like a pretty easy problem. (Of course it would.) But after recently working with the “bitmap trace” feature in products like Adobe Illustrator and Macromedia Flash, which tries to recognize lines in order to create vectors from pixels, I can vouch for the fact that computer scientists still have a long way to go when it comes to the “line finding” problem. “I see the line so clearly, why can’t the computer?!”

This makes for some fascinating reading.

http://music.calarts.edu/~david/mediaworks/on_being_invis_ii.html

On Being Invisible is a self–organizing, dynamical system, rather than a fixed musical composition. The title refers to the role of the individual within an evolving, dynamical environment, who makes decisions concerning when and how to be a conscious initiator of action and when simply to allow her or his individual, internal dynamics to co–evolve within the macroscopic dynamics of the system as a whole.

…

One of the primary objectives in this research was to achieve the technical capability necessary to create an attention–dependent sonic environment. I wanted to create a situation in which the syntax of a sonic language orders itself according to the manner in which sound is perceived. To accomplish this, components of the electroencephalogram (EEG) recorded from the brains of on–stage performers, known as event–related potentials (ERP’s), are detected, measured and analyzed.

I’ve gotta get me an EEG machine…

I’ll be giving a tutorial on XSLT 1.0 at the O’Reilly Open Source Convention this August.

Here’s the full quote from Thomas Merton, now that I’ve got the New Seeds of Contemplation checked out from the library.

Fickleness and indecision are signs of self-love.

If you can never make up your mind what God wills for you, but are always veering from one opinion to another, from one practice to another, from one method to another, it may be an indication that you are trying to get around God’s will and do your own with a quiet conscience.

As soon as God gets you in one monastery you want to be in another.

As soon as you taste one way of prayer, you want to try another. You are always making resolutions and breaking them by counterresolutions. You ask your confessor and do not remember the answers. Before you finish one book you begin another, and with every book you read you change the whole plan of your interior life.

Soon you will have no interior life at all. Your whole existence will be a patchwork of confused desires and daydreams and velleities in which you do nothing except defeat the work of grace: for all this is an elaborate subconscious device of your nature to resist God, Whose work in your soul demands the sacrifice of all that you desire and delight in, and, indeed, of all that you are.

So keep still, and let Him do some work.

This is what it means to renounce not only pleasures and possessions, but even you own self.

The last thing I want to do is defeat the work of grace. God help me.

I bought my first Moleskine journals tonight (a small squared notebook and a large ruled notebook).

I intend to use some combination of these and 3×5 cards to implement the “Getting Things Done” system.

One idea I had was to use one 3×5 card for each Next Action and then store them in the accordion folder at the back of my Moleskine (probably the large one). A good preliminary exercise would be to destroy some cards just to start getting the feel for it and to break past any conservatism that would keep me from freely dispensing with the cards. Actually, I can leverage my own desire to preserve my nice things by keeping the card count small so as not to put too much wear and tear on my expensive Moleskine. That could be a good motivating factor for knocking things off my Next Actions pile.

Anyway, here are some of the blog entries that inspired me this evening:

Moleskine GTD tabs hack
Introducing the Hipster PDA

I read a passage from Thomas Merton at Barnes & Noble this evening that hit me right between the eyes. Unfortunately, I couldn’t find the quote online, except for this small excerpt. Maybe I’ll post it after I eventually buy the book.

Fickleness and indecision are signs of self-love. If you can never make up your mind what God wills for you, but are always veering from one opinion to another … from one method to another, it may be an indication that you are trying to get around God’s will and do your own with a quiet conscience. So keep still, and let God do some work.

The rest of the section included a couple examples that hit home–like starting another book before finishing the one you’re on, and starting new life pursuits every other day on every random whim. “Bilateral incongruence” is a related term I’ve come across (in the context of NLP). Also, this passage touched on what it means to fully give one’s life to God.

There. I placed a hold on it through Seattle Public Library.

This quote (by Scottish mountaineer W. H. Murray) was one of a million things that I reflected on the night that I decided to turn down an awesome job offer to pursue a new (yet old) dream:

Until one is committed, there is hesitancy, the chance to draw back, always ineffectiveness. Concerning all acts of initiative (and creation), there is one elementary truth the ignorance of which kills countless ideas and splendid plans: that the moment one definitely commits oneself, then Providence moves too. A whole stream of events issues from the decision, raising in one’s favor all manner of unforeseen incidents, meetings and material assistance, which no man could have dreamt would have come his way.

The next step is trusting in God and waiting with expectancy and planning the details and trusting in God.