Halebopp - A Kind of Working Prototype

I have been busy hacking on halebopp the past two weeks, and this weekend I managed to come up with something that is kind of some use, by which I mean that it's of no use at all.

Originally, in humble spirit, I intended to break the news once there was something presentable, and only then, but since I'm a fool and need to boast about it everytime I made two inches of progress, here it is, a not-so-quick-but-at-least-I-tried announcement.

Halebopp is supposed to become a "keep-it-simple recording studio for electronic music artists, with extensive support for fast and sloppy workflows". Right now it is more kind of a "what the hell is this crap there's a white box and some red lines, is it election day?" application.

The project site is right here (click on the word "here" to find out what "here" means). Find the source tab, yet another referrer. You should then have arrived at a page where there is a Mercurial repository URL, it's right in the basement, guarded by a siberian tiger. You can't miss it.

Assumed that the project is checked out, to build it you will need:

• Ubuntu (although any other distro will not be fine)
• Python 2.5
• Lord g++ and his numerous one-or-two-letter henchmen (= build-essentials)
• clutter and python-clutter (you need to roll your own, I used 0.8.*)
  
• APSW 3.5.9 and SQLite3 with a matching version number (not available in Ubuntu 8.04 or 8.10, you need to build it yourself, I'm sorry)
• portaudio v19 (roll your own from a daily snapshot, I'm making use of the JACK client name extension)
• portmidi/porttime (distro version is allright)
• Boost.Python (distro version will do fine)
• libsndfile (distro version is disco version)
• to skip this silly dispensable bullet

Got everything? Good. Because I fooled you. There is no program to run. Turn around now.

You have not turned around. That means I have to give you build instructions. They go like this:

(assumed you are in the project folder):
# ./waf configure -d debug
# ./waf build

That's it. Run the app:
# ./run.py

At the moment there is nothing to install, unless someone submits an installation patch for waf. You people seem to be way better at deployment than I ever was.

Before you start the program the first time, make sure that a folder ~/.halebopp exists.

Oh yes, some directions for the stuff you are seeing. If halebopp does not use the right soundcard or gets MIDI or audio in/out wrong, check run() in halebopp/__init__.py to enter the proper device number (like 'd0' or 'd1') for both audio and midi, in this order. The default program output should give you a list of available devices. I had success with both ALSA and JACK. Midi is not doing much at the moment except initializing, so don't be too worried about it.

Now for what you can actually do with it. At the top of the screen you see a small red line and a landscape that looks like Alaska. This is your recording buffer, or recbuffer, which measures about 30 seconds of time. The recbuffer is always on, and records straight from the soundcards input. It gives you access to the last 30 seconds of recorded sound.

The big red line below the recbuffer is your actual play cursor. Hit SPACE to play/pause. Click the left mouse button anywhere (without dragging) to move the play cursor. There is no navigation yet.

When you select a portion in the recbuffer, your selection is made permanent ("realized"), and immediately transforms on the main canvas. Your realized recordings will always be placed where the play cursor was when you recorded it. This way you could e.g. sing to a previously recorded track, realize your new recording, and it's going to be placed in synch to the previously recorded track.

At the moment there is no editing of tracks. Your view is fixed to 30 seconds.

All changes on the song are directly written to a song database in ~/.halebopp/song.db, so you can close the program at any point, and when you open it you will return right to where you left off.

That's it so far.

YouTube Follows XKCD Suggestion

It seems the guys over at YouTube are also reading my favorite webcomic, XKCD.

A few days ago, XKCD featured this comic.

This morning, when visiting YouTube, I found an "Audio Preview" button next to the "Post Comment" button.


Needless to say, it works as advertised. I nearly pissed my pants.

Crowd Programming

Now here is one of these weird ideas I keep having, although people are asking me to cut the crap. But I think, as usual, that it is really great, and so I leave it up to you to decide if this makes sense, or just constitutes a parody of a Web 2.0 service.

Imagine a webservice for programmers, let's call it "Codr", where programmers would translate each others verbal commands into code for, let's say, Python.

A typical example:

1. Jane logs into Codr and adds a verbal command she'd like to see translated, such as "print out the square root of a number".
2. John likes to translate verbal commands into code, sees the verbal command on the "new commands to translate" page and translates it into his favorite programming language, Python. The translation reads print math.sqrt(number). Codr is able to deduce required modules and input variables from the given statement, so it can put the statement into other contexts. John also marks "a number" from the command to be replaceable by any int or float datatype.
   
3. Now Joe logs into Codr and adds a meta-translation for "print the distance between two points", which goes like "for each dimension of a point, subtract the destination number from the starting number, multiply each result with itself, add up all results, then print the square root of the result." Some of these statements still need translation, but the last statement could already be replaced by its translation.

Over time, the database would be filled with semantic translations which would create a huge database of code snippets where users could search for a recipe to solve a coding problem, and since statements can be combined to greater statements, at some point, coders could merely state their intentions of what the code should do, and the site would translate recursively all parts of the implications where Python translations are available.

The longer the site runs, the more problems can be solved, maybe even for different frameworks and languages. Also, library coders could write translations for how their library would solve the problem, for example.