[Golist] Flashbelt

Tue May 27 06:30:11 PDT 2008

interesting (esp. considering jared is speaking at this show).
is there any way that i could show it with the sound working?
-m

On May 27, 2008, at 4:31 AM, Martin Wood-Mitrovski wrote:

> 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
>
> _______________________________________________
> GoList mailing list
> GoList at goasap.org
> http://goasap.org/mailman/listinfo/golist_goasap.org