Sunday, October 30, 2011

Synaesthesia 2.4 for Windows

It seems like a lot of "music visualization" plugins just use music as a random seed for interesting visual effects. There is a link between changes in music and changes on screen, but there's no real collection between individual elements of music and individual elements on screen. The best software I know of for visualizing music is Synaesthesia. It presents an image with the horizontal axis being stereo and the vertical axis being frequency. Images can directly correspond to individual sounds, and so I can see sounds on the screen as I'm hearing them. The program truly deserves the name Synaesthesia.

Until now, the only publicly released Windows version was an old port based on Synaesthesia 1.2. The current version of Synaesthesia is 2.4, and there are many new features since 1.2. A long time ago I started working on a port of Synaesthesia as a Winamp plugin. However, I learned that GPL licensed code (Synaesthesia) can't be used in a plugin for an application that has an incompatible license (Winamp). I just created a new port based on Synaesthesia 2.4, the 1.2 Windows port and some of my code. You can download it from Dropbox. Further information is available within "Synaesthesia 2.4 Windows port readme.txt" in that zip file.

This is just a quick port I created today. There may be bugs. Please don't bother the original authors of Synaesthesia and the 1.2 port. If you run into problems, leave a comment here.

2 comments:

Boris Gjenero said...

Internally, Synaesthesia uses a 2D "colour space" with 8 bits per colour component. Output is at 8 bits per pixel, with 4 bits per colour component. The palette is used to translate from this 2D space to RGB space. When the colour sliders are adjusted, they adjust the palette to change the colour seen on the display. This is an elegant use of old 8bpp display hardware with palettes, but nowadays 32bpp display modes are common, with 8 bits for each of red, green and blue. I just wrote a small experimental patch for 32bpp output. It's not optimized, but at today's CPU speeds that's ok. It gets rid of the colour banding that's seen occassionally at 8bpp. I'm not sure if that matters, because the banding doesn't have to be thought of as a defect. It also introduces a defect: the default fade mode doesn't fade the 8 bit values all the way down to 0. (This is irrelevant in 8bpp mode, where the 4 least significant bits are ignored.)

Boris Gjenero said...

Here's a patch which fixes the fading issue when using 32bpp output. It uses a lookup table for fading. The table was created using a linear interpolation of the output of the original algorithm. It's quite faithful to the original. The only differences are smoothing of variations that were artifacts of the algorithm, and fading by at least 1 at low brightness.