After Dave’s blog post put out the call for 50 visualizations using the new Audio API in Firefox 4 I decided it was time to stop thinking about learning processing and its .js version and time to start doing things with it.  So I took a few hours on Saturday to poke at the code that Dave put up and after a lot of shots in the dark I came up with this but I was disappointed in how simple my results seemed after so much time spent.  Today I went back to the book and learned a few more processing tricks which inspired me to hack on the audio visualizations again.

For my second attempt I really tried to understand more what the javascript functions were doing, how the actual audio data was being generated, and in what form it was being passed to the processing draw() function.  I found a couple of pages on the Mozilla Developer Network that helped me understand the API a bit better.  On my second attempt to visualize audio data I could really make it do what I wanted. The next round of learning I would like to do in this area is how to work with user interaction better. To respond with audio and video to user movements and key press events.

Second attempt at audio visualization

I’m really glad Dave put out the challenge, and that I made the time to teach myself something new.

Our fabulous intern Anamaria Stoica has been working hard the past few months helping to pull data from buildbot’s scheduler DB that allows us to learn all sorts of new information about how the release infrastructure is being used, and how it could be optimized. Among other things, she’s generated an end-to-end report so we can see at a glance how long the complete build cycle for any push to mozilla-central took.  Now, on top of that, she’s added a way to see who is using the awesome new TryChooser syntax.

In the coming weeks I’ll be emailing folks who are using try but not the TryChooser syntax and encouraging them to give it a shot. In my stock email letter I will say something along the lines of:

When you use the TryChooser syntax to make requests for only what you need, you allow precious CPU cycle time to be used elsewhere by those who need it.

This is helpful for two reasons:

1. Those testing fixes to blockers of the next beta/rc/release can get try results quickly and get their code landed on trunk
2. Overall wait times for try results are reduced

What’s interesting in looking at the reports though is that more of the pushes to try that use TryChooser are green. Here’s a snapshot of those who are using TryChooser:

The number of build requests is an aggregate of all the builders triggered so all build types, platforms, test and talos builders run on that push.

Now for comparison, here’s a snapshot of folks not using the TryChooser:

I have no way of knowing from this snapshot which of those pushes were intentionally not using the TryChooser and perhaps trying to get all 176 possible builds. Some of them may be using custom mozconfigs as a way to kill off unwanted builds (p.s. you get burning with that).

If you haven’t tried it yet, please give TryChooser a go and see if getting a smaller set of builds (ie: what you need, not just the default) and perhaps getting more green on you try pushes gives you a boost.