hasen

For the past couple months, I’ve been feeling stuck. Every time I sit down and try to get something done, I can’t. I find myself “dreading” the thought of going through all the troubles involved (working out some minor low level details, etc). So instead of doing work, I’d procrastinate on youtube or facebook or what have you.

I tried to pin down why I was having this mental block that prevented me from doing work. I thought: maybe I’m worrying about the code quality. I know that my code won’t be perfect and elegant, and that disturbed me. Maybe that was one of the reasons. Maybe I was worried about my “reputation”; it’s not that I have any reputation online (I’m pretty much a nobody), but when potential employers are reviewing my work (say, on github), they may think I’m a messy programmer when they see my messy code.

So, I made a mental note (I also wrote down these thoughts on a file) of these worries and how they could be stopping me, but that didn’t quite get rid of my problems. I still felt “stuck”. I still couldn’t get much done.

And then one day, I decided to do some “doodling” (after I read an article on HN about how doodling helps your brain when you’re bored). I doodled random non-sense for about a minute, and then I found myself sketching a UI for an iPad app that’s been in my head for a while now. I didn’t just draw some boxes; I also wrote down some notes about how various elements should behave. Then after that, I found myself sketching out another version of the same app but for the web. I didn’t only sketch it, but I also sketched out the basic structure of the code behind it. I basically wrote a high level view of the code that would make it run. Then I worked out some of the mathematical details. All that on paper. All these ideas have been in my head for a while, but I wasn’t able to express them as code; I was stuck; I had a mental block. But now, I expressed them on paper. This got me excited, so I went to my laptop right away and started translating this stuff into code.

This time, I didn’t have anything to worry about. I didn’t have any psychological worry about how things will turn out. I was basically code-monkeying my sketch. I wasn’t thinking while I was coding, I had already figured things out on paper, so my coding consisted of me looking at the sketch and writing it down in the programming language I was doing my app in. I was plagiarizing from my sketch.

There were a few details which I didn’t get right on paper, but they were easy to fix. And in very little time, I got a working prototype of my idea.

And then I realized that this is the way to go. And I also realized what exactly was happening, and why sketching is the solution.

I’m an INTP, and I think this applies to xNTP types. I don’t know if it applies the same to xNTJs.

What happens when I have lots of ideas that I want to express in code is the following: I have a rough/vague picture in my head representing the structure of my program. As soon as I start writing code, I have to concentrate on the details of the code I’m writing now, and this means that there’s no more room in my mind for that general “picture” I just mentioned. This is a problem because: I don’t want to lose this picture in my head; if I lose it, I won’t get it back easily. It’s basically the same thing when you are in flow and then suddenly you’re interrupted. You need a lot of time to build the house of cards, and you can’t afford to let it fall apart; it’s mentally devastating.

This is where sketching comes in. When you sketch the idea on paper, you have the entire picture in your head, and you’re translating it on paper. Because it’s just paper, you don’t have to worry about details; you’re not writing code; you’re just sketching; there is no need for your mind to do any context switching. After you layout the general structure, you can then dive into some corners and work out some of the details in a very rough/general manner. Again, because it’s on paper, you get to control how deep you want to dive in, and because the structure is already written on paper, you don’t have to rebuild it in your head; you just look at it again and delve into the next detail (if needed).

Then you can translate this into code, and you will not have the problem of context switching. Why? Because you’re not worried about preserving the “mental picture” of the general structure of your idea. This way, you don’t have to think a lot while you’re coding, you’ve already done the thinking and produced this sketch. Now you can just follow your own sketch, like a code-monkey.

Why is this related to psychological type? Well, It’s related to how you organize and express your thoughts. In the classical MBTI/Jung theory, INTPs organize logical structure internally (introverted thinking) and express ideas and intuitions externally (extroverted intuition).

When thinking, you get alot of ideas, and you want to express all of them. The problem is, if you try to express them in code directly, you can’t, because it will take quite some time to express each idea, and working on one idea at a time kills you, because you have all these other ideas that also want to be expressed, at the same time! And you know that if you start detailing some idea before the other ideas got a chance to be expressed, you’ll lose them. So, by righting down a sketch of these ideas on paper, you can express all of them in a rough basic form. This way, all of your ideas get to be expressed at the “same time”, and this clears up “cognitive space” in your brain to start working on the details of each idea.

Like I said, maybe this doesn’t apply to INTJs, who constitute about half the programmers/hackers out there, but I’d be interested to know if any INTJ tries this and finds it helpful.

This sketching business is not entirely new to me. I used to do it a lot in the past. In fact, now that I think about it, most of my non-trivial programs in the past were sketched out on paper first before I started coding them, otherwise they probably wouldn’t have been possible. I just didn’t realize how important/pivotal it was. I don’t remember how/when did I stop doing it. Maybe somehow I got the impression that real hackers just sit down and churn out code.

I’ve been thinking for a long time about building a “writing” platform. But when I try to put it into simple words, it sounds like “oh, yet another blog”. In fact I’ve even written a post before titled “yet another blog engine”. It’s been probably over a year, and the thing is still only in my head.

Most current blog engines are like magazines. You write something, and it gets filed under the date it was published in! If you write an essay, why should it matter whether you wrote it around 15/4/2006 or around 8/10/2007? Most of the time, the exact date doesn’t matter. Just a general time line is usually enough, “2006”. If the date does matter for a certain essay, you can add it as a note somewhere.

When I think about an essay here, I’m thinking about things that might go in books, more so than newspapers. And in books, you don’t usually get a date around every essay or chapter. Books are a bit more “timeless” than magazines in this sense. There’s usually only one date on a book: the year it was published.

This is actually inspired by Paul Graham’s essays page.

If most current writing platforms (manifested as blog engines) are designed more around a magazine concept, then there ought to be a place in the market for writing platforms that are designed more around the “book” concept.

It’s certainly possible to write essays on top of current blog engines; I’ve seen several people do it, but it’s somewhat annoying, and you get a lot of other little problems. I’m sort of doing something similar with Tumblr here, though not quite so.

The nature of essays is that they can evolve. You write a piece, revise it, revise it, revise it, then publish it. You get lots of criticism, people comment about how stupid you are, etc, and maybe you will want to edit it, to sort of elaborate some problem points. OK, maybe you have a thick skin and you can ignore trolls, good for you. But still, say you change your opinion about something, or you learn of something you didn’t know before, so you want to go back and revise your essay.

So in this sense, each essay is like its own project, you work on it, publish it, but you can never really say it’s “done”; there’s always room for changes and improvements. So it’s ought to be possible for you to completely “own” your project, independently of the web platform where you’re publishing it. You should be able to work on it locally on your machine. Blogs don’t usually give you that kind of freedom. There might be some APIs for importing and exporting blog posts, but that doesn’t quite cut it. I’m thinking of ownership here in terms of how you own your project that you’ve published on github. You have the git repository on your local machine, all the time. If github disappears, you can publish your local git repository somewhere else. If Google disappears, all your blog posts and Google Docs also disappear. (It’s much more likely for your computer to break down than for Google to disappear, but it’s always possible that Google may suspend your account and delete your content).

Another important thing for this kind of writing platform is how the content is presented. Most blogs allow you to make your blog ugly and stupid in all kinds of different ways. Silly color schemes, useless widgets everywhere, picture backgrounds, etc. I much prefer there be a single, good, minimal theme, or just a few of them to choose from.

Pen.io seems like a such a writing platform, though it doesn’t fulfill the content-ownership I talked about.

Google Docs also allows you to do pretty much the same, and it’s much better at being a writing tool than pen.io and other blogs, but it’s not “webby” at all. You can “publish” your writings, but they have a long cryptic URL, and there are no interaction features what so ever.

Any writing and publishing platform on the web needs to have some way of interacting with readers and the rest of the web. Some kind of a commenting system seems necessary. I’m not sure if comments should be right on the essay page (like most blogs) or in a separate place. For some reason I prefer to have the comments somewhat “detached” from the essay itself, but at the same time readily accessible from it. A simple way to do that is by having a link at the top and/or bottom of the essay to a “discussion page”. The discussion page would also have a link to the original essay at the top and/or the bottom.

I just had this idea. The title of a wepage should try to be as short as possible. Perhaps a 5-letter word.

1. Titles (along with icons) are used to recognize tabs in a multi-tabbed browser. Keep that in mind. For the title to be useful, it has to be short, otherwise the browser will cut it.

2. Titles are also used when creating bookmarks; long titles force the user to do the useless task of editing a bookmark name from “YouTube! Broadcase yourself!” to “uTube”. Why not just make it “uTube” to begin with?

codedump:

function mkcd() {
  [ -n "$1" ] && mkdir -p "$@" && cd "$1";
}

Example:

user@host:~$ cd work
user@host:~/work$ mkcd website.com/{html,src,stuff}
user@host:~/work/website.com/html$

Please be warned again that this is not my area of expertise. Don’t take anything I say too seriously. At best anything I say it just a reasonable approximation that happens to work for me.

I’m assuming you’re trying to generate musical tones, so I’ll talk about frequencies as if you already know what frequency you want to produce. I will also be using coffee-script and the Firefox Audio Data API.

The max value of a sample is 1.0 and the min value is -1.0 so all samples will be between these two values (these are the “peaks” of the volume).

Frequency / Period

If you consider a sound sample to be a sequence of a repeating shape, then count how many times per second does the shape repeat? This is called the “period” (e.g. the period of the sample/signal). The frequency then will be 1/p (where p is the period).

If your sample rate is SRATE, then that’s how many samples are there in a second. So, to get how many samples are required to generate one period p, it’s srate/freq.

Technically this is the “fundamental frequency” but I’m not too deep on the math of signal processing.

Sine waves

Sine waves produce a pure “peeeeeeep” sound. Generally speaking a sine wave is a good start when you’re hacking around, but I don’t know if you can get far enough with it. The formula for generating a sound wave doesn’t require calculating the period or anything like that; just the frequency.

The formula for it is simple mathematically: given a point in a long sound sample (think of point as index):

sine = (freq, point) ->
    k = 2 * Math.PI * freq / SRATE
    Math.sin(k * point)

This is not very efficient as you keep calculating k over and over, so:

sine = (freq) ->
    k = 2 * Math.PI * freq / SRATE
    (point) -> Math.sin(k * point)

Now sine(440) returns a function that takes a point and returns a sample value.

Sine waves are not very interesting like I already said. I thought we’d build more complex sounds on top of them, but it turns out they’re not needed at all when synthesizing string sounds using the karplus-strong algorithm. Perhaps sine waves are useful when generating sounds in another way.

There are a few extra things you should take note of, I already mentioned them here:

Quick notes on generating sine waves

Basically you’ll need to dampen the signal using e^(-5x) (you can change 5 to 4 or something else — feel free to experiment with it). To get x you have to know when do you want the signal to end.

In code would look like this:

dampen = (point, lastpoint) ->
    x = point / lastpoint
    Math.pow(Math.E, x * -5)

When you write the output, you multiply the sample from sine by the damp factor from dampen.

And the pink noise process is dead simple: you multiply the signal by 100/freq

s = sinefn(point)
d = dampen(point, lastpoint)
p = 100/freq
output[point] = s * d * p

Wavetables

Another way to generate sound is to use a pre-populated list. For some reason this list is called a wavetable. Please don’t confuse this table with hash-tables or dictionaries: it’s just an array of values.

For a sound of frequency freq, the size of the wavetable is SRATE/freq. Now this actually doesn’t produce exactly the desired frequency, but a close enough frequency that the ear can’t differentiate really.

See, if you want to generate a wavetable for the frequency 440, here’s what would happen:

coffee> SRATE = 96000
96000
coffee> freq = 440
440
coffee> SRATE/freq
218.1818181818182
coffee> Math.floor SRATE/freq
218
coffee> SRATE / 218
440.3669724770642

The period length would be 218, but that’s the period associated with frequency 440.4. This difference is like I said small enough that the human ear doesn’t notice a thing.

So if you pre-populate an array of this size, you can generate the samples on the fly:

length = Math.round SRATE/freq
wavetable = new Float32Array(length)
# fill table somehow
(point) ->
    wavetable[point % length]

Since the process of pre-populating itself can be time-consuming, we can do it lazily:

(point) ->
    if point < length
        wavetable[point] = wavefn(point)
    else
        wavetable[point % length]

This leads us to the Karplus-Strong method of synthesizing guitar strings, which I already wrote about here:

Very simple implementation of Karplus-Strong algorithm in coffeescript

Note that it doesn’t make use of sine waves at all. Instead, it starts with a noise sample and causes it to decay in a very simple-minded way. It’s very surprising (to me at least) that it manages to generate a sound like that.

OK, this sums up my experience so far. Unfortunately I haven’t come across the ultimate function that can generate any kind of musical instrument :) but that ok, since it wasn’t my goal to begin with.

I’m a bit over excited as I just managed to successfully implement Karplus-Strong’s guitar string algorithm.

http://en.wikipedia.org/wiki/Karplus-Strong_string_synthesis

The Wikipedia description was too complicated for me. I had to get the original paper and try to study it. It’s rather old and the terminology was a bit weird, so it took me a while to really understand it.

This snippet assumes you have SRATE defined somewhere (the sample rate), and that you already managed to setup the audio output and the mixer and everything else. I’m using audiodata.js to output audio using Firefox4’s Audio Data API.

The function guitar here returns a function which takes a sample index/point and returns the sample. It assumes that it will be called with all the samples sequentially, otherwise it won’t work. Something like:

signal_fn = guitar(440) # 440 being the frequency we want to sound

point = 0
while not done
    sample = signal_fn(point++)
    # output sample

Not exactly that, but something like that.

Here’s the code:

period_len = (freq) -> Math.floor (SRATE/freq)

avg = (a, b) -> (a + b) / 2

ks_noise_sample = (val) ->
    # get either val or -val with 50% chance
    if Math.random() > 0.5
        val
    else
        -val

# karplus strong algorithm
guitar = (freq) ->
    samples = period_len freq
    table = new Float32Array(samples)
    getsample = (index) ->
        point = index % samples
        if index == point
            table[point] = ks_noise_sample(1)
        else
            prev = (index - 1) % samples
            table[point] = avg(table[point], table[prev])

Note that this is coffee-script, where the last expression in a function is returned, and A = B expressions return B. So, guitar returns the getsample function, and getsample return table[point] after we calculate it.

Here’s what this does:

Fill a table of length p with random values (actually: fill it with either A or -A, with 50% chance each). Where p is the period of the signal, which is the sample_rate/frequency.

To produce samples, just keep cycling on this table. That is, to get any point t, take table[t % p].

BUT, as you loop on the table, average each two adjacent samples. That is, everytime you get table[t] (except the first time around), let table[t] be (table[t] + table[t-1]) / 2.

This causes the signal to decay overtime, or something like that.

That’s it.

A few notes based on my experiments the past couple of days.

First, when you manage to generate a sine wave, you’ll notice there’s a “clicking” sound at the end. Where does it come from and how to deal with it? I think it comes from having the volume suddenly drop to 0. So to make it go away, you gotta make the wave form fade away slowly and gradually.

The graph of e^(-2x) looks like a good smooth path for that.

Second, you’ll notes that high frequencies sound way louder than low frequencies. To work around that, multiply the samples by 1/freq (see: pink noise). This makes each tone sound the same loudness. (In reality you use a multiple of 1/freq, for for instance, I used 100/freq.

I realize this is way out of context and perhaps won’t make sense to most people. I’ll talk more about generating sound waves later. But I wanted to jot down these quick notes before I forget.

Express, the node.js framework, uses mime to automatically find the mime-type of any statically served file.

If you have a text file with a certain extension and it’s being served as binary, you can serve it as text by defining its mime-type within mine.

For example, I had a .coffee file and I wanted express to serve it as a text file, so here’s what I did:

# let .coffee files be served as text
mime = require "mime"
mime.define({'text/coffeescript' : ['coffee']})

Basically you call mime.define and give it an object formatted like this:

{
     'mime-type' : ['list', 'of', 'extensions'],
     'mime-type' : ['list', 'of', 'extensions'],
     'mime-type' : ['list', 'of', 'extensions'],
}

For example:

{
     'text/plain' : ['cpp', 'c', 'd', 'java']
}

In other words, keys are mime-types, values are a list of extensions that should be served with that mime-type.

That’s all you need to do. The rest happens automatically.