chrishowie.com

I have finished removing Lua from Kaffeeklatsch and have enhanced Affe with the ability to bind field, property, and method calls at runtime. I noticed this gap when rewriting some of the key binding scripts; where I could just set a field before, my compiler threw an exception since it could not find the field on the IEffect interface. After wrestling with this for a while I finally came up with another hackish solution: a new operator.

The period operator binds during compilation, and the new dollar sign operator binds during runtime. Instead of the standard target-arguments-call emission, it emits a call to a static method declared inside Affe that takes the target object, the member name, and an object[] containing the call parameters. This method performs logic similar to a compiler-bound call (in fact, basically identical logic) except using the target’s runtime type. One annoying pitfall of this technique is that since the return type cannot be known at compile time, a late-bound invoke necessarily returns an object. And, of course, to unbox a primitive you must perform an exact cast.

Since I didn’t unbox automatically I added a parenthetical cast operator to Affe so that late-bound return values can be unboxed or converted. (Note that boxing is automatic.)

So where something like Effect("fountain").Rotate = true; would make Affe choke, this can now be written as Effect("fountain")$Rotate = true;.

I am toying with the idea of flagging certain types to be intelligently bound. For example, if IEffect was so flagged, the compiler would try resolving the call and if it could not bind it, would convert the expression to a late-bound call. This would give all the speed of compile-time binding where possible, and fall back on runtime binding when that failed. Since I’m trying to make Affe basically a fast scripting language for .NET, this is optimal. It may make debugging harder since errors are not caught at compile time, but you’d have that problem with the $ operator anyway.

I got Kaffeeklatsch back out of the toy box the other day and started integrating the Affe compiler into it. The goal is to remove Lua entirely, as it’s an unmanaged dependency and has been giving some odd errors as of late, crashing mono after a few seconds.

The SuperScope effect has been completely converted over from Lua to Affe. (Keybindings and the Custom effect are next on the list.) To celebrate this achievement I have posted a teaser video on Google Video. The quality is pretty horrible and there is no audio, but you get the general idea:

There are a few effects you are seeing here:

• Clear screen is responsible for the slow fadeout to black.
• The flames, blue scope, and neon lines are all instances of the SuperScope effect with different Affe scripts.
• The multicolored star is a FountainScope effect.
• About 13 seconds in I turned the Laser effect on. This instance draws moving black rays from the center.

Every effect is a managed object; SuperScope is the only one in this video that uses user-supplied scripts; the others can have other parameters tweaked from the Gtk# preset designer.

I’ve finally put Kaffeeklatsch in a Subversion repository, and a public one at that! Simply check out from https://layla.chrishowie.com/svn/kaffeeklatsch and build… well the build process isn’t that simple, but oh well. You will need Tao, the Lua 5.0 library and development headers (check your distro’s packages), and Mono. Having MonoDevelop around will make the build process a bit easier.

Happy new year, and happy visualizing!

I’ve been making some small progress on Kaffeeklatsch, though most of it is behind the scenes stuff. For example, IEffect now extends IDisposable, and the frontend will dispose effects when removing them. This could be used, for example, in plugins that create OpenGL display lists and want to properly clean up after themselves when destroyed.

At the moment, the core effect library is lacking a dynamic movement plugin, which should deform the color buffer according to a user-supplied formula. I heard that Winamp AVS was made open-source some time ago, so it may be a simple job of porting that effect to C#. However, as this kind of math is not really my area of expertise, I would love for another FOSS developer to join the project and help out there. Post a comment if you’re interested.

It’s coming together slowly. Recently Kaffeeklatsch has been enhanced with Lua, which is used for key bindings and in several effects. For example, there is a “Custom” effect that simply runs a Lua script each frame. The script gets full access to OpenGL by default, but can access any loaded .NET classes. (This could be a security problem in the future, but it’s not a major concern right now.) Key bindings simply run a Lua script that is given access to the entire effect list, allowing bindings to do anything — manipulate properties and fields, and invoke methods. So a key binding can toggle multiple effects, change colors, you name it. You can also bind a different script to a key press and a key release, allowing for tap/hit effects.

Also available is an effect called SuperScope, which users of Winamp’s AVS will immediately recognize. The implementation uses Lua, and is almost completely compatible with Winamp’s implementation. With a little work, it will be 100% compatible. At first it was unbearably slow. More than 128 points with sync at 75hz (basically 128 * 75 = 9,600 points per second) would cause a significant drop in framerate. This was due to the implementation: the “point” script was compiled once per frame, and invoked n times by C#, the relevant global variables extracted, and the vertex drawn with OpenGL, through Tao. For each point. Whew.

I decided this needed to be fixed. The solution is not pretty, but it’s very effective. I moved the point loop into Lua, and wrote a small glue library in C that exposed glColor4d and glVertex2d to Lua, effectively bypassing a .NET-to-Lua call for every point — now only once per frame. I can now get up to 2,048 vertices, 75 times per second, before performance suffers.

A beta release may be coming soon. But first I need to find the source of a bug that manages to terminate mono with no stack trace after a few minutes of rendering.

Time bombs suck.

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.