Actionscript3, Flash, Scala, Java, C#, C++, Algorithms & Imageprocessing
We have finally released the first version of the Audiotool. I am very thankful for all the kind tweets and happy that our work is now available to the public.
However the current version is named Firestarter for a reason. What you see online is just the tip of the iceberg. I can not wait to start implementing all the cool features that will separate us from traditional software ;)
We have release a small update of the AudioTool and included André’s ToneMatrix. Some features that have been implemented in the last weeks are online as well. Removing an effect for instance will not destroy the cables. The desktop scales now without interrupting the audio output and various other performance tweaks have been made.
When you are implementing a pathfinding algorithm you have usually some sort of defined map available. This is in most cases a tile map or a graph of nodes. If you have no nodes and no tiles you have two options: build a graph of nodes or put your smooth environment into a raster with a defined detail. Option two is usually faster but we have choosen number one for asthetic pleasure in the AudioTool. And we showed that building such a graph at runtime in Flash is something you can do if you implement clever optimizations.
You will always have problems without some kind of raster. Sometimes more, sometimes less. Usually you have to build your own context of how things are connected and how they behave in your environment. We were discussing a lot about the audio engine and the core structure behind. The most important part of the audio engine is probably the ability to build a linear chain of plugins which process signals that arrive in your speakers at the end of that chain. When we started this part we had a lot of optimizations in mind. Plugins that do not generate any audible output should not go into that chain etc. The code became quite complex and results in a lot of special case scenarios. Imagine a scope which is a pure visual element that shows the incomming waveform. This is a plugin which should not be kicked out of any chain but generates no audible output.
You can imagine that we used a graph for that kind of task. To be more specific: a directed cyclic graph since there is a direction of the flow and we are allowing feedbacks for audio signals. After some time of discussion I started researching for a better way of solving our signal chain. Because I beleive that a problem can be solved the easiest way on a pure mathematical basis I started with a plain graph — but this time a real graph. After some time I could produce the same output as our old solver but with less lines of code and we got rid of all the special cases.
Now having a real graph is fun and I was not surprised that lots of people invested their brainpower in graph algorithms. For the desktop in the AudioTool I always wanted to implement some kind of automatic layout algorithm. My first idea was to build a spring between two editors connected by a cable. I thought that this could be too complex but after spending the last days with graphs this became a possible solution and there are already algorithms which do the same thing: build springs for connections and let the system solve itself. I did some tests in a sandbox already but hopefully I can implement this in the AudioTool before FITC Amsterdam. The graph you see in the picture is a result of the graph layout engine.
But working with graphs opened my eyes even more. I am currently the poor bugger that has to implement a layout engine. Implementing a layout engine is by the way the most ungrateful task I could think of. 
Anyways, what if you think about the dependencies in your layout engine as a graph structure? You have usually three cases when calculating a size: relative known size to “some kind of available size”, absolute known size, absolute unknown size. Those cases can be reduced to their most simple form on a piece of paper and a graph structure evolves. You can get rid of observers and listeners in such a system if a connection in the graph has the meaning of invoking the layout engine again on a subset of nodes. Those subsets could be optimized even more if you figure out the strongly connected components in the graph. I have to admit that I did not implement this system yet but it makes a lot of sense in theory currently… something which makes working on a layout engine interesting again ;)
This is what you can get when you combine a Lemur with the AudioTool and map some controls to the Rasselbock. I really hope that we can release the Midi feature to the public soon because it is just so much fun!
I just put up a site with all the AudioTool recordings that I think are quite interesting. It is way easier to share them like that instead of posting about every single track.
I will also put some more sets and other tracks there if I find the time. The site will update randomly.
Here are the slides from my Flash On The Beach 2008 session “AudioTool’s Private Parts”. 2mb without a prelaoder. You will need Flash Player 10 to pass through to version detection or you can save the SWF directly to disk and watch it with Flash Player 9.
Last night I spent about 9 hours writing a build script for the AudioTool allowing us to compile each plugin into its own SWF container. I think it is the first time a Flash project is taking more than 5 minutes for me to compile completly.
I figured out that it is definitly not easy to handle the mxmlc or compc in a way we needed it to be. The point is that we have for each plugin three modules A, B, C and a library D. A depends on D. B depends on A and D. C depends on A, B and D. Now to make it even more complex we have A, B, C and D in one project so that developing in this environment stays still simple. The solution to compile all modules in a way we need them to be was first generating unique entry points for the SWF files because we do not want to work with SWC libraries (or the SWF inside the SWC package). After having the unique entry points we compile D (and its dependencies as well) without including the source of A, B or C. Afterwards we can compile A. But B is dependent on A so we have to compile a SWF for A and then a SWC for A so B can link to A as an external library. C is also analog to this but needs B as a library as well. In the end it was 5am and I was happy to have the complete build working which generates a lot of SWF files and SWC libraries.
Since it is very hard to configure Ant for this (I was using XSL in the beginning for automated code generation) I started developing my own Ant tasks. I have to say that it is really simple and saved us hours of work. We have now one single XML file containing the dependencies and the Ant task will do the rest (code generation, compile tasks, etc.).
Last friday was an awesome day. It was my birthday, Microsoft released Photosynth which is a product I have been watching since two years and we won the FlashForward Award in the category Sound with our Audiotool.
The Audiotool development became a very interesting topic. We implemented so many things to keep stuff optimized not only on the code layer but also on the algorithm layer. I am really looking forward to talk about some techniques in my session “Audiotool’s Private Parts” at Flash on the beach and Flash on tap.
Besides implementing OggVorbis I was working on an effect for a while. It is called the Rasselbock and will probably not make it into the next launch but since I love the device so much I have some top-secret recordings of what that little guy can do.
It is basically an IDM/glitch-type effect unit with a lot of cool features. It supports sequenced effects like gate, stutter, etc. and keeps them synchronized to the beat. A killer feature is that it includes also a sequenced mixing unit. This sounds maybe a little bit bizzare but once you can play with it you will probably love it.
All of these songs were made in about 5 minutes and are very cheap. Anyways it is a lot of fun to take any sort of instrument (like a metronome) and route it through the Rasselbock.
