Tagged:generative art

MIDI-driven Flash: Synaesthesia for Everyone!

Typical music visualisers, as found in desktop media players, have limited means to analyse the music played through them. Audio data from a mixed-down track is a blend of waveforms, normally from many sources. Spectral analysis allows amplitude variation at disparate frequencies to be detected and graphed discretely, which can assist in beat detection and tempo analysis. But due to the noisiness (…) of this data, huge variation in compositional arrangements and the need for realtime processing, the majority of visualisers have limited reactivity and focus on producing partially-randomised, generative animation that would be pretty even if running on white noise.

No.

But that’s all for raw audio. Samplers and virtual instruments (rendering MIDI data) have ever-increasing prominence in music creation and live performance – and greatly outclass standard hardware MIDI synthesizers, with which the typical notion of dorky, low-quality MIDI playback is inexorably tied. Compared to an audio stream, ‘message’-based music protocols describe events – normally pitch and velocity/volume information about notes triggering on and off – and nothing about the timbre of the sound, allowing sonic quality (for instance, the performing instrument) to be altered at any point.

Visualising musical data in this form removes all uncertainty around the timing and nature of note events (along with the overhead of detecting such details), accommodating far tighter correspondence between the audio and visual elements than is possible with conventional visualisers.

The Future

And none of this is new – VJs have been leveraging MIDI precision for years, and the field is still growing – but routing note data into Flash is new to me, and something I’d wanted to do for years, provoked by rhythmic music that carried a strong sense of motion, or was otherwise very visual. (Lookin’ at you guys, MSTRKRFT and Susumu Yokota <3 – among many others.)

There are several possible starting points for running MIDI into Flash, but none especially mature (at least on Windows; different options are available for OS X). The primary issue is that the Flash runtime has never interfaced with environment-level MIDI APIs, which is pretty much in-keeping with conventional use of the platform. Various workarounds are possible, and having read around a lot I settled on the following:

  • Translate the MIDI data into OSC (a newer protocol and likely eventual successor to MIDI, designed to run through the network transport layer), with the VST plugin, OSCGlue, created by Sebastian Oschatz.
  • Receive the OSC packets with the Java flosc server, created by Benjamin Chun, and retransmit them over TCP (OSC data is normally sent over UDP, which Flash does not support).
  • Receive the shiny new TCP-delivered OSC packets with the OSCConnection classes, an XMLConnection extension written by Adam Robertson and revised by Ignacio Delgado.
    (Worth mentioning: the updated flosc server (v2.0.3) given at the Google Code link above didn’t work for me, but I had no problems with the original on Ben Chun’s site (v0.3.1).)

Here is a demo of it running, routing percussive hits from Ableton Live:

The visualisation method (best referred to, generously, as a ‘sketch’ for now), comprises an array of ‘particles’, distributed in 3D space, accelerating and rotating in time with note-on messages. On snare hits, the background gradient is also switched-out for another. The particles themselves comprise a few other graphical experiments: all symbols are a singular colour, but appear different due to variations in their layer BlendMode; I also created a sliding shutter-mask for the otherwise circular symbols in the Flash Pro IDE before embedding them; and I attempted a depth-of-field blur effect by increasing filter strength with distance from the camera – but it’s all a little abstract for that to be very applicable.

You can play with the visualiser ‘offline’, using keypresses: arrow keys (or WASD for the homicidally inclined) to move the particles; spacebar to swap the background. (Note: you’ll probably have to click into the player first.)

Some disclaimers: most of the work outside of Flash was that of the developers cited above; I don’t mean to take credit. This write-up is mostly to aid visitors with the same intentions, riding in on the Google express, since no other documented method I came across suited my needs and/or worked.
And, secondly, the visualiser itself is intended primarily as a tech demo and precursor to a more complete, aesthetic (…synaesthetic?) piece. You’ll see – it’ll be just like having a real mental disorder.

Webcam experiment: dynamic pseudo-3D modelling

This is an extension of a little app I made around a year ago, which coloured and filled boxes with hex values based on the sampled colours of an image. Like this!:

That, however, was inspired bybased on … blatantly copied from some images by the hugely talented Luigi De Aloisio.

In the name of originality, and boredom, I more recently hooked the same function up to the Camera class, and updated the grid every frame. Useful if you need to know precisely what web colours your face is made up of, but the whole challenge with the original app was finding a good source image that would remain discernible once grid-ified, so most of the time you’re stuck with meaningless coloured blocks. (As a lifelong fan of Sesame Street, that was enough for me, but I’m trying to make a career out of this stuff.)

Removing the text and squarin’ up the rectangles, you effectively get an over-pixelated form of the video feed – just like having a webcam from the 90s! I thought it might be interesting to dynamically update the z-axis position of each cell, and overall brightness seemed to be the most sensible property to sample. It looks like this:

So, to recap what’s happening: per frame, the feed from the camera is sampled at regular intervals, across a grid of specified resolution, to capture the pixel colour at each point (I couldn’t afford the overhead of averaging across each blocks’ area). On the first pass, for each cell, a Shape object is created, filled with a square, and added to the grid array. On subsequent passes, each Shape object’s colorTransform property is set to the sampled pixel colour (computationally preferable to clearing and redrawing the square, but not hugely). The R, G and B values composing the cell colour are then averaged and normalised, before being used to move the cell backwards along the z-axis by an amount proportional to its darkness. (Because darker things are further away, sometimes, maybe…? It more or less works for the shadowy areas in faces anyway.)

The squares look ok, but with the grid floating in 3D space, I thought it might look cooler to use solid blocks instead. Unfortunately your CPU will not find it cooler. Quite the opposite; performance isn’t great with this one:

The code differences here involved replacing each Shape object with a Sprite (in order to contain the multiple cube sides), and the four extra panels were drawn and rotated into position. Side colours were varied to make the blocks appear shaded, and on updating the colorTransform property, the three channel multipliers were each set to 0.6, in order to avoid washing the shading out altogether.

Next steps? As I’m yet to identify a practical application for all this, there’s little need to have it running in a browser or on Flash at all, so I may take a crack at porting it to Processing or C++ with OpenGL, for the perfomance gain. It might be nice to see it draw one box per pixel, or to to use the brightness to set the Z co-ordinate of vertices rather than faces, and then stretch the video over a surface. A plain ol’ wireframe mesh might look nice too.

Any feedback on performance would be great.


Edit: Source code uploaded to my github repository here.

Hello

I'm Adam Vernon: front-end developer, free-time photographer, small-hours musician and general-purpose humanoid.