A short introduction to call-with-current-continuation -
Learning about lisp/scheme continuations .. wow .. what a mind twisting concept!
And there I thought lisp lacked structured exit points like “break” and “continue” and “return” ..
This is just brilliant .. I’m so humbled.
When I finally understood how the coroutine implementation works on top of call/cc (it wasn’t obvious how that worked), I felt a sense of awe at the beauty and magnificence. I almost want to cry :”]
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.
SuperAgent: ajax library without the suck (by visionmedia)
LiveReload: automatically reload browser page when editing local files -
The official site doesn’t make it clear, but it works on linux too
Fix for when mongodb won't start on Ubuntu -
Kinda lame ..
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.
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.
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?
I’m just looking around for tutorials, and just found this (haven’t even read it yet, but seeing as its in the official wiki, it’s gotta be good).
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).
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 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
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.
I only do music as a small hobby on the side. I know almost nothing about western music theory, and I know only very very little tiny bit of middle eastern music theory.
But, I think I know enough to start making a music keyboard application, so I’ll try to pass what I know for anybody who is interested in this kind of thing.
I’ll try to be brief as much as I can.
A really important note: please don’t take my word for anything I will say, I’m pretty much an ignorant in this field, and I only know basic dumbed down stuff. While this model should work in practice, the ideas presented here do not necessarily represent reality, so be warned.
You know how the piano keyboard has white and black keys? And they have a pattern that repeats? When you press a key, you get a certain “tone”, when you press a different key, you get a different “tone”, and it’s the production of these tones together in sequence that creates melodies.
So:
Each key produces a tone
Each tone has a frequency, and its defined by its frequency. So if you know the frequency of a certain tone, you can generate it.
This is not entirely true of course. We’re ignoring many aspects of the actual sound you hear. You can produce the same tone from a guitar or a piano, and they will sound different, but the tone will be the same. So think of tones as something a bit more abstract than the actual sound you hear.
Tones (in the abstract sense) lie on a linear scale, so we can represent tones using real numbers, and we can talk about the distance between tones.
Take a look at the piano keyboard:
In that picture, I’ve numbered the keys sequentially. The first two white keys are 1 and 3, each has a distinct tone. The distance between these two tones is said to be 1 unit. In other words, we define one unit of tonal distance as the distance between the first two white keys on the piano octave.
In Western notation, the white keys are, in order, are notated by: C D E F G A B
Notice the black key, 2, which lies between 1 and 3. The distance between 1 and 2 is said to be half a tone, and the distance between 2 and 3 is also half a tone.
In other words, on the piano, each two adjacent keys have a distance of 0.5 tone between them (half tones).
Note that #1 and #3 are not adjacent; they are separated by #2. However, #5 and #6 are adjacent; there’s no black note in between them, and so the distance between them is half a tone.
You can also get quarter tones by getting the tone between 1 and 2. The piano has no key to get this tone, but rest assured that it exists. This is a limitation of the piano keyboard; not all instruments suffer this limitation.
Western music only uses half tones, but Middle Eastern music uses quarter tones. This means that there are middle eastern melodies that can’t really be played on the piano because the piano lacks some of the required tones. For instance, this piece on the Rast scale is an example of such a melody (although you can probably approximate it somewhat).
Notice how the pattern on the piano keyboard keeps repeating? These are “octaves”. I don’t know exactly what’s an octave, but you can notice key #1 always produces the same “note” but in higher or lower pitch. When I say “same note”, I don’t really know what I’m talking about, so just take it at face value. Also take it with a grain of salt. It’s not the “same same note”, it’s more like “same note, different octave”. So note #13 is (kinda) the same as note #1 but on a different octave, but they’re still different notes in that one of them has a number #1 and the note has a number #13, and #13 has a higher pitch.
(Note: I’m being rather liberal in my terminology here, I use “tone” to mean “the actual sound you hear”, and “note” as “a way we denote musical tones”. I don’t know if this coincides with the canonical usage of these terms or not).
Tones don’t map to frequencies linearly. The mapping is more, exponential, I suppose. Fortunately there’s a simple mathematical formula that will find the frequency of any given tone.
def freq(n):
return 440 * pow(2, n/12)
Where n represents the tone in terms of how many half-steps it’s away from the A4 tone. That is the A note, on the fourth octave. A is note #10 in my picture above. But what’s the fourth octave? Well to be honest I don’t know which octave is the first, but it’s all relative and I think you should try to measure it by ear and the whole point is to pick a base to start numbering tones.
The important thing is that this formula allows us to find out the frequency for each key on the piano.
This formula works for arbitrary real numbers, so n could be 1.5, and this is a good thing because it allows us to produce quarter tones and arbitrary microtones.
This is important for me because I actually want to support quarter tones and other microtones, so the application I have in mind will not really work like a piano keyboard. Instead, the interface will be something that allows you to map keys to arbitrary tones, so you can make up your own scale.
If you do some more math, you can adapt the formula above to different units, for example, I think the 12 comes from the fact that we divide each octave to 12 parts, and 440 is just the frequency of A4. You can change these numbers.
Here’s a more generic function:
def freqn(tone, base=440, tpo=12):
return base * pow(2, float(tone)/tpo)
This allows you to choose an arbitrary base frequency base and divide an octave into an arbitrary number of notes tpo (tones per octave). For example, if you wish you could divide an octave into 6 tones, this way the tone parameter actually represents the tonal distance.
You should note that I made this up, and I suck at math, so do the math yourself and don’t take my word for it (though I’m pretty sure it works).
In theory, producing a musical tone requires only knowing the frequency for the tone. What I mean is, given the frequency of a tone as the only input, a machine can generate (synthesize) the musical tone.
So now you have a mock up of the UI, and you can figure out what frequency to play for each key.
How do you actually produce a sound with that frequency? And how can you make it sound like some specific instrument?
This is something I myself am still experimenting with, so maybe I’ll make another post about it sometime later.
So, for now, the rest is left as an exercise to the reader :P
This bit is not necessary to create a music keyboard, but it’s something I’m interested in for my particular application.
Let’s go back to the white keys on the piano. Why are they differentiated from black keys? The white keys are mapped to the C Major scale. If you play the white keys in sequence, they sound nice together. If you play all the white keys AND all the black keys, they sound a bit weird. If you replace some white keys with black keys, they may sound nice together.
Don’t ask me why, I don’t know :)
You may notice that different combination of keys have a different sort of feel to them.
I define a scale by two things: a starting point and a series of “tonal distances”.
The C Major scale starts at note C and the distances are: [1, 1, 0.5, 1, 1, 1, 0.5] and then it keeps repeating. (Again, we’re defining 1 tonal distance as the distance between C and D).
The names of the notes C D E F G A B are mapped on the C Major scale. That is, the distance between E and F is 0.5, which is different from the distance between C and D.
If you change the starting point of a scale, but keep the distances, you can still play the same melodies and they will sound pretty much the same.
There are many, many scales. maqamworld provides a decent database of middle eastern scales. For instance, here’s the Rast scale, notice the distances are: [1, 0.75, 0.75, 1, 1, 0.75, 0.75]. That’s why I said earlier that you can’t play it on a piano. If you look closely, it’s very similar to the Major scale. The only difference is the third note and the seventh note.
Major:
o - - - o - - - o - o - - - o - - - o - - - o - o
Rast:
o - - - o - - o - - o - - - o - - - o - - o - - o
Generating Sound in Firefox 4 -
A 2 minute video tutorial included!