chrishowie.com

And so does Kaffeeklatsch. Now, anyway.

First, I added preset saving and loading a few days ago but never wrote about it. Since then I gave the design of this project some serious thought, and moved some classes around into strictly defined layers:

• Kaffeeklatsch Visualization Platform. The generic components of the platform: the effect interface, effect registry, display controller, and preset serialization methods.
• Core effect library. Basic effects that most users would expect, and a few small examples.
• Preset designer. Gtk# visual preset designer.

I moved as much common functionality as possible into the platform layer. Preset serialization, which was originally in the designer, was moved there to ensure a common preset format across different software that uses the platform. The controller was also in the designer — I’m still not sure why I put it there to start with.

There is still one loose end: media player connectivity. Currently that is split between the platform and designer layers. It’ll probably all be moved into the platform, with an extension mechanism for talking to different media players.

Kaffeeklatsch is quickly becoming exactly what I wanted it to be: cross platform, media player neutral, human controlled visualization. Huzzah!

Just a day later and all Kaffeeklatsch needs now is key bindings, then we’re ready for “production,” whatever that is.

This screenshot highlights the two biggest additions I coded today: the automatic generation of option pages for each effect (see the sources displayed!) and the gathering of scope data from XMMS. A small stub plugin sends the waveform and spectrum data to a UDP port on localhost, which Kaffeeklatsch picks up and passes to the effect renderers. Kludges rock.

If I didn’t mention it, this project will be released under the GPL. At least when I decide it’s not too embarrasing to release.

The sources displayed in the image are © 2006 Chris Howie and are available under the terms of the GNU General Public License version 2, or (at your option) any later version.

I was digging through some of my old, unfinished projects this week and found one that I’d barely started. The goal was to write a scriptable audio visualization tool in C, approaching this art form differently than most viz tools today.

As a former light tech for a band that toured the US (and abroad, though I didn’t go on that tour) such plugins have never fully scratched my creative itch. I’ve played with the two leaders: Winamp AVS and Milkdrop. Both leave me with a feeling that so much more is possible, if only I could bypass the computer’s often inaccurate idea of what looks good. I want control over what is displayed at all times.

Enter Kaffeeklatsch: a fully managed C# visualization application. It does not require connectivity to an audio player to visualize — because you, not the music, control what it does. Just about every action possible from the effect designer can be bound to a key press or key release. (There will be an option to stream audio data from some media players for scope and similar effects.)

And effect plugins are a breeze to write. If you’ve ever wanted more from visualizers, Kaffeeklatsch provides a clean, elegant plugin interface. Public fields and properties can be tagged as options, enabling the designer to automatically generate option pages; public methods tagged as triggers will be automatic candidates for key bindings.

Kaffeeklatsch: Visualization reborn.

One of the things I do miss about Windows is the abundance of universal trainers for it. If you don’t know what a trainer is, it’s a program that writes over the memory of another process, typically a game, to confuse the program into doing something it wouldn’t normally do. Trainers are often used to get infinite lives/money/ammo in games. However, they must know where in memory these variables are being stored.

A universal trainer is the most generic trainer: it allows the user to search a process’ memory space for a certain value, and further refine the search until the variable’s location in memory is isolated. Then the user may modify that memory to change that variable while the program is running.

Kcheat is the only similar program I’ve seen for Linux. Unfortunately, it requires KDE 1… which nobody is going to install just to use this program.

Well, Wednesday I decided it might be cool to design a new one. So I did, using portions of Kcheat (mainly the lower level stuff). It’s implemented in C# with Gtk# as the UI, and a small C library to take care of the nasty work. As of last night it’s almost done — already! It can search the memory of a process for six different data types (signed/unsigned 8/16/32-bit integers) and allow their contents to be tweaked. It’s a little unstable as I haven’t done any exception handling yet (except where necessary) but the stable release will be pretty slick. The UI is uncluttered and simple, though demand may see the addition of new features.

The only drawback is that the project is generally pointless: most Linux games that people care about are either network games, which prevent clients from tampering with the data on the server, and the others are open source anyway, so you can just comment out the “if (lives == 0)” line and recompile.

On the other hand, this is easier than recompiling, if a bit hackish.