NoiseCradle 2 will adopt a client/server architecture, allowing multiple clients to access and modify the rendering tree maintained by a single server. The graphical application used to control NoiseCradle is the "standard" client.

One of the ideas behind this architecture is to allow anyone to write their own client which they can use instead of (or in addition to) the standard client. In the same way that Google Chrome uses multiple processes to try and stop your whole browser from crashing when things go wrong, NoiseCradle clients will each run in a separate process. If a client goes wrong, the server (which is responsible for audio processing and rendering the visual output) will continue to run.

A NoiseCradle client communicates with a server over TCP by sending and receiving streams of XML messages. For example when a client first connects it can request the current rendering tree by sending:

<get_workspace></get_workspace>

The server responds with an XML representation of the tree, which can then be updated by the client based on events received from the server. A Java library will be released to abstract away these low level details, however the full XML protocol will be published to enable developers to implement clients in other languages.

This post gives an overview of the planned software architecture for the next release of NoiseCradle. It is aimed primarily at potential developers, although hopefully normal users will also find it an interesting read.

NoiseCradle is being redesigned to consist of separate client and server components. The server component will be responsible for audio processing and rendering the visual output. A client component connects to a server and is then able to manipulate its visual output, typically by modifying the rendering graph. Regular users will simply run a single client and server on the same machine. This configuration will be setup automatically when NoiseCradle is opened and therefore wont be any more complicated than opening the current version. The new architecture does however enable some more advanced features, including:

• Controlling NoiseCradle from a remote machine. For example if you run NoiseCradle in fullscreen mode on your desktop machine, you will still be able to control it from a remote provided that both machines are connected to a network.
• Multiple users collaborating on a single visualisation project (by simultaneously connecting their clients to the same server).

Eventually we hope to make the server API public, allowing anyone to develop their own client. This will allow serious users to develop and use their own tools for controlling NoiseCradle visualisations. In addition we plan to release an API to allow users to develop their own visualisations for use within NoiseCradle. Visualisations will be written in Java/OpenGL. Java will also be the recommended language for client development (although in theory it should be possible to use any language that can establish a TCP connection with the server).

An overview of the planned software architecture can be seen below. As always feel free to ask questions or post comments in the forum.

On a final note, we have posted a video on Facebook demonstrating playlists as described in our last few blog entries. Visit our Facebook page to find out more:

Last year we introduced the idea of visual playlists. We have now decided that they should be the "base" element of every NoiseCradle project, rather than graphs as is the case in the current version. Users wishing to re-create the old graph style can simply use playlists which only contain a single scene! Below is an example of what the new interface might look like.

This playlist shows the Oscilloscope scene for five seconds, fades over seven seconds to a Circles scene (which is shown for a further six seconds). A re-arrange effect is then applied to the Circles scene before fading back to the original Oscilloscope.

Another week, more new functionality. In the next version of NoiseCradle you will be able to drag and drop media directly onto the rendering graph from Windows Explorer:

This removes the need to first import media into the NoiseCradle media list, which will be removed or replaced by a more general purpose disk browser. Automated controls which previously relied on the imported media will have per-instance media lists, allowing you to create several automated controllers which make use of different media files :).