Like many musicians, I enjoy watching live music because it gives me a chance to see how the performers play. For most instruments, this works well -- but keyboard players' hands are generally hidden from the audience by their instrument. Classical pianists usually get around this by facing away from the audience when they play; a few rock keyboardists solve the problem by using a keytar, or a keyboard on a stand tilted away from them.

I'd like to solve this by building a keyboard that doesn't obscure the player's hands: the key mechanism would be designed so that no counterweight would be used at the back of the key, meaning that the keyboard casing could be completely flat at the level of the keys. If a counterweight is necessary, it could be coupled to the key using gears from beneath.

I think it'd be particularly neat if this could be made to work with a real acoustic piano -- but even for a MIDI keyboard, this would allow a weighted keyboard to be built with an unusually minimal appearance.

Several machines I run spend most of their CPU time doing SpamAssassin analysis. SpamAssassin applies a very large set of rules to incoming messages in order to decide whether they're spam. Each rule has a positive or negative score, and the sum of all the scores for the rules that fired is compared against a threshold.

When filtering mail, once you've passed the score needed to tell a message is junk, there's no point in running rules that will increase the score more. You can therefore limit yourself to only the rules that may reduce the score. If it drops below the threshold again, you can go back to trying positive-score rules. In order to prove a message is spam, you only have to make sure you've run all the rules that might help to prove it isn't.

If we use this approach, where the positive-score rules don't always get used, then it would also make sense to keep track of which rules are most likely to fire, and try those first.

User interfaces don't make much use of relative mouse movement at the moment -- other than the odd knob-like adjustment tool, or gestures (which I've never been terribly convinced about as a UI concept). Given that laptop users are often forced to use an inherently-relative trackpad (or occasionally a stick) instead of a real mouse, it'd be useful to minimise the amount of fiddly absolute positioning necessary in mouse-based interfaces.

A mostly-keyboard-controlled window manager could use relative movement to shuffle windows around: you press a number key to select a window, then drag it to its new location using the mouse. This more than halves the distance you have to move the mouse, which would be a great advantage on a trackpad.

A text editor could use mouse or scrollwheel movement to adjust numbers in text, using a logarithmic scale so that it wouldn't matter how big they were to start with. (Or log vertical and linear horizontal, or similar.) This'd be great for a live-feedback TeX editor.

Players of stringed or tuned-percussion instruments will be familiar with the concept of sympathetic resonance: if I play a C on the piano with the damper lifted, all the other Cs (and, to a lesser extent, the Gs, and so on) will resonate along with it -- and continue to do so even if I damp the original C.

It would be possible to construct a "tuned reverb" system, based on the same principle as a plate reverb, but seeking to maximise rather than minimise tuned resonance. (Imagine clamping a speaker and contact microphone to a piano frame.) This could be used to provide a resonant backing behind a solo instrument -- although the player would probably want a damper pedal to stop the resonance when changing chords, in the same way a pianist does. I've seen this done to great effect when using a MIDI-equipped guitar and a synthesiser, but this would work with any sound, including the human voice.

Of course, you probably wouldn't build this in real life; you'd simulate it using something like Pd...

Oolite is an open-source game set in the Elite universe. I spent far too much time playing the Amiga version of Elite many years ago, and I think Oolite's great; they've struck just the right balance between the playability of the original Elite and the realism of Frontier and FFE.

One way in which they've chosen to stick with Elite's behaviour is in how the ship handles: there's no momentum. This is fine by me, since my major problem with Frontier was that I kept flying into planets by accident. However, they've implemented Frontier's engine plume animation, and the faster you move forwards, the bigger your engine plume gets -- which makes no sense, unless they're claiming that the ship really does have no momentum.

I don't think this is the case; by the time of Oolite, navigation systems are smart enough that they're just providing the illusion to the pilot that the ship is momentumless. The pilot doesn't control the engines directly; the navigation system does whatever's necessary to make the real ship do what the pilot wants.

It's therefore fairly straightforward to make the plume animation match reality: just have Oolite figure out what direction the navigation system must be accelerating in, and point the engine plume that way. The result should be quite pretty to look at.

This clears up some of the oddities of the game world. The ship has a speed limit because the thrusters can only maintain the illusion up to a certain speed -- for example, pulling up in a smooth curve only works if you limit the forward velocity. (The fuel injectors don't break this rule, since if you're going faster forwards you need more thrust to compensate.) It also explains why in-system fuel is essentially free -- you aren't using any except when you change direction.

On the other hand, it would also be nice to be able to disable the momentumless interface when necessary (i.e. toggle between the Elite and Frontier control modes). This would let you get a better top speed at the cost of maneuverability, or accelerate to a high speed and then rotate to shoot backwards with your forward weaponry. (Perhaps "advanced flight controls" should be a high tech-level -- or perhaps illegal -- upgrade.)

Nearly every car stereo system has four speakers situated roughly at the corners of the car, so it's an obvious environment for surround sound -- and, indeed, back in the 8-track era, several manufacturers produced in-car Quad-8 players. I think it's time for a quad revival.

These days, most car stereos have CD players, some kind of digital audio processing engine, and four separate power amplifiers, which means it should cost next to nothing to add support for decoding surround sound. There are a number of formats that could be supported.

SQ and QS are simple matrixed encodings, used on many quadraphonic LPs in the 1970s. In some cases, the CD releases of these recordings kept the surround information intact; Mike Oldfield's "Hergest Ridge" is one example. Dolby Surround and Pro Logic are more recent matrix systems, and have already been implemented in some car stereos.

Compressed surround sound, using DTS, AC3 and similar codecs, has been available in various consumer products for years. The "5.1 Music Disc" format from the late 90s used standard audio CDs containing DTS rather than PCM audio; few titles are available in the format, but since they're as cheap to produce as a normal CD they're still available and relatively inexpensive.

The compressed-audio decoders present in many car stereos present a new option for "compatible surround" CDs: store the front channels as regular CD audio tracks, and the rear channels as MP3 or similar files on data tracks. You'd have to read the surround data into a buffer first, but you can probably get away with relatively low bitrates for the rear speakers.

There are also a number of schemes for simulating surround sound from a two-channel recording. The classic Hafler circuit (feeding the back speakers with the difference between the front speakers) is trivial to implement. Many surround amps use delays or reverbs to synthesise a rear channel.

I'm currently looking at changing the mail-archive-to-HTML system I use -- which is largely painless, but has the disadvantage that all the URLs to individual messages will change. I could reverse-engineer both systems and figure out how it's generating filenames based on the messages, but I think there's probably an easier approach.

I'm imagining a "make-redirects" tool. Given two trees of documents, this program should identify pairs of similar documents in the "old" and "new" trees, and emit an Apache config file with Redirect directives in. The documents don't need to be identical, just as close as possible (containing the largest percentage of identical text) -- it seems unlikely to me that this wouldn't work for mail archives.

The same approach could be used to deal in a mostly automatic way with web content moving around on any site -- and even with smaller documents being merged into one larger one. (The other way around would require generation of a stub page, and would be a bit harder to detect automatically.)

One of the major problems with backlit LCDs is that the backlight must be on all the time -- meaning that a lot of power is wasted as heat from absorbed light, and it's not possible to get a true black on the display.

To solve a different problem (motion portrayal), people have recently suggested using a grid of LEDs as a backlight which are scanned like a CRT beam. This would be useful for moving video, but scanning is irritating for mostly-still images (such as computer screens).

The grid of LEDs could be used in a different way -- as a smart backlight that only generated as much light as was necessary in each bit of the screen, using the LCD elements to add fine detail. Essentially, you'd display a low-resolution black-and-white version of the desired image on the LEDs, and the difference between that and the desired image on the LCD.

This would significantly reduce power usage from the backlight, and would allow dark areas to be truly dark. You would end up with not-quite-dark artefacts in the shape of LED grid cells around single light pixels, though; it might be best to low-pass filter (and then brighten) the backlight image to avoid sharp transitions in the backlight intensity between cells.

Daniel Drucker pointed out that this is remarkably similar to the display being developed for the One Laptop Per Child project, which includes a number of interesting new display technologies.

The completion facilities offered by readline and similar libraries are very useful for command-line users, but they aren't very easy to discover -- particularly when the completion rules are complicated, and the user may not know that their shell is able to completion what they're currently typing.

I'd like it if readline would show the current completion in a pale colour after what I'm currently typing -- so I can see instantly what would get completed if I hit Tab. This would invariably add some extra overhead, but in many cases (such as completing filenames in a directory, or command-line options from a parsed --help message) caching the results of the lookup the first time would get around this, and the completion lookup could start running in the background as soon as a completable word is detected.

This is a bit of interface design straight out of the TV series NCIS -- but I figured it actually looked pretty sensible.

I'd like a window manager that's similar to dwm -- i.e. showing one large active window, and lots of smaller inactive windows in a column down one side -- but taking advantage of compositing so that the inactive windows were just scaled down, rather than actually being resized. I'd find this convenient for, say, editing text while watching TV in a window, since it'd be easy to toggle which of the windows occupied the main area while having a reasonable overview of what's in the others (although doing that efficiently would require integrating the XVideo extension with the compositor).

It'd also be useful to have a keybinding that'd make the active window occupy the full screen, completely hiding the inactive windows, and I'd like to be able to show more than one "active" window in the main area (say, two side by side). Actually, why isn't there a good scriptable window manager framework that'd let me write this sort of thing in a high-level language without having to implement all the compositing stuff myself?

Donald Stewart wrote to point out that xmonad is almost the window manager I'm after here, and since it's written in Haskell it's ideal for me to play with...