[Golist] Flashbelt

[Martin Wood-Mitrovski]

Moses Gunesch wrote:

> Bribes and guilt-trips aside, ;) if anyone is just excited to share  
> some of your Go work, this is a really great chance to get the word  
> out to the wider community. In fact if you're going to attend  
> Flashbelt it would be great if you want to give a short presentation  
> of your material there, so please keep me posted!

well, I cant come although id like to, but im finally getting somewhere with my app.

Here's the latest demo :

http://relivethefuture.com/code/flash/app.html

So, at the top left is the 'toolbar' for creating new box types (only 3 at the 
moment,but more to come soon).

At the right is the box inspector for altering parameters and configuring the 
nodes in a box.

When you create a box you'll see it has its own set of controls, from left to 
right :

Inspect : Show box params / nodes in inspector.
Close   : remove the box
Zoom    : zoom a single box to the whole work area

Then the last 2 function as a mini-transport for IPlayable's

Play / Pause and a Stop button (although just play / pause would probably be 
sufficient in this case)

What does GO do ?

1. The app UI animations.

I used HydroTween to animate the various bits, box creation, box zooming, box 
removal (just dont try to remove more than one box at a time or it gets 
confused...although im working on it)

Also if you inspect a box and select the 'nodes' panel you'll see that as you 
select a node the 'selected item glow' is also tweened.

Donovan you've done a great job with HydroTween, its really straightforward and 
easy to use.

2. Box contents

Each box is an MVC component where the model is driven by Go.

The PathBox uses a couple of LinearGo / LinearRepeater subclasses which allow 
for changing the properties while its running (duration, easing, number of 
cycles). It also has a custom correctValue which keeps the output value between 
0 and 1, but does it so that numbers outside the range wrap back into the range, 
i.e. 1.3 -> 0.3, -0.4 -> 0.6.

That means that when you use an easing function like Bounce or Elastic it doesnt 
blow up the path interpolation function :)

The IKBox and OrbitBox just use a model which extends PlayableItem as they only 
need to receive update messages. Of course the big win with using Go is that I 
dont have to worry about managing timers or frame loops and I can just plug in 
the same transport mechanism for starting / pausing / stopping.

3. Socket dataflow control

This isnt actually in the online demo because the app is designed for 
communicating with other audio applications via OSC (Open Sound Control).

Using the GO update allows me to control when the socket buffer is flushed. This 
is important because within the OSC protocol there are 2 types of messages

1. OSC Message
2. OSC Bundle

An OSC Bundle is actually a container for OSC Messages (basically an array of 
messages).

If I was to send every change as an OSC message when it happened I could be 
looking at something in the range of 30 messages every update. So if the update 
is running at 60 fps that gives 1800 messages per second.

Because each message would be sent as a single TCP packet I would incur a 
minimum of 32 bytes overhead for every message. Thats 57600 bytes per second (or 
56k)

With the flow control, I buffer all the messages between each update frame and 
send them as a bundle, which means I generally use 1 TCP packet per frame, or 60 
per second. That works out as 1920 bytes per second (or 1.9k).

That saves over 50k per second. (of course its slightly more complicated because 
if the bundle is bigger than the MTU it will get split up anyway, but im just 
demonstrating the best case scenario :)

The other upside is that the OSC server which is receiving these packets can 
spend less time context switching. If its processing every packet individually 
then it has to run through its full pipeline each time a packet is received 
(depending on its implementation of course), whereas with bundled data it can 
stay in the packet processing code for longer (less object churn, better chance 
of cache hits for the CPU etc..)

For real-time audio its important to maximise the amount of time spent doing 
real work because otherwise you either need a longer latency to minimise the 
chance of not filling the audio buffer, or you'll get audio glitches. Neither of 
which is really acceptable for what I want to do with this project :)

so, thats probably more information than any of you wanted to know about what im 
doing, but I wanted to show how using Go just lets me focus on what I want to 
achieve and how it isnt just for 'visual tweening' (although its obviously great 
for that when using something like HydroTween)

i'll take this text and put it onto my wiki page on the playground later :)

thanks,

Martin