Our labs team has released ALAC in Coffeescript.

ALAC is Apple’s proprietary lossless audio format. It’s mainly used for audio production, not for consumer listening. Apple released their source code not long ago and we did a port from C to Javascript, using bleeding edge browse APIs to actually render the waveforms.

This codec was never going to become a standard. It was never to going to be playable in any browser without a fairly rare plugin. But using Javascript in a browser supporting these new audio APIs, everybody can now play this codec without installing anything.

Open source, on Github.

Links:

• Devon’s blog on JS advances has the details.
• Conversation in French on Korben’s blog.
• The Hacker News thread about it.

We have posted a new version of our Desktop Track Manager. This is a client-side app that helps with common tasks for artists. It’s especially useful for uploading multiple files at a time.

The biggest improvement is good performance for people with a lot of files, but also there were a bunch of pinpoint fixes.

Here is the change log:

To pick up the new version, go to http://bit.ly/vl2q39.

The core contributors on this project were Emilie de Fouchécour and Thibault Béné.

If your unit tests are slow, it’s hard to debug the problem.  We have released a tool to help  Rails developers speed up tests. This tool is called “Top Tests.”

To help you figure out where the problems are, Top Tests shows you a list of the ten slowest tests. Run times are shown, and the list is sorted from the worst on down. It’s like a profiler that tells you about runtime performance, except that it tells you about performance of your tests instead of your app.

To enable you to include test performance in your unit tests, Top Tests allows you to fail the build if any test takes too long. The timeout is a configurable parameter.

Our tool is open source under a BSD license. Code and detailed documentation is on Github at https://github.com/officialfm/top_tests.

We use lots of open source from other people and are happy to get to give back. We hope this is useful.

The core contributor on this project was Alexis Bernard.

We’re looking for a developer with skills in the browser stack – HTML, CSS, Javascript. You must be up to date: HTML5, CSS3, current ideas about JS.

The person who is the right fit for this job is probably mid-career. This wouldn’t be your first job after university.

This is a full time job in our Geneva office. You’ll need to speak French and some English. You’ll need to be able to work legally in Switzerland (most EU people are).

Be a person with energy and passion, somebody who’s really happy when they make something fantastic.

Email jobs@official.fm. Tell us about yourself. What have you made? Got source?

It’s with great pleasure that I announce you the release of officialfm-php v0.1.0 and officialfm-ruby v0.1.1, both of which support all endpoints of the Official.fm Advanced API.

By navigating the developer docs, you can see that the Advanced API uses OAuth 1.0a to allow users to log in with their own credentials in a secure way, without ever needing to ask for their password.

This means that you can now create web applications that can fully manipulate a user’s profile, such as changing his name, bio, uploading a new avatar, but also uploading new tracks, modifying existing ones, and assembling playlists fully through the API. These new endpoints open up a world of possibilities for Official.fm web applications. One could create multi-track editors fully in the browser, that could even run on mobile devices!

However, the OAuth sign-in flow is not exactly trivial. First, a request token must be obtained by prodiving your application key and consumer secret. Then, you have to redirect the user to an authorize request URL on official.fm. Then, once the user has authorized your application, he wll be redirected to a callback page in your application, then providing you with the token which will be used to sign all further communication.

Fortunately, there exists Ruby and PHP libraries to help with OAuth. In Ruby, we recommend using omniauth, which integrates nicely into Rails. We provide an example of sign-in with Official.fm in Ruby using Rails 3 and omniaut on GitHub. As for PHP, it seems that the stock oauth module handles request_token incorrectly, using a GET request instead of a POST request, so it doesn’t work correctly. We recommend instead using the oauth-php library, which has the added bonus of not using any native code. As for Ruby, we provide an example PHP application for OAuth sign-in on GitHub.

If you create an application using the Advanced API, mention us on Twitter and we might feature it on this blog!

In the previous posts, we have reviewed the Ruby bindings and the PHP bindings for our Simple API. As a reminder, the Simple API allows you to retrieve users, tracks, and playlists information. Using the ‘embed’ parameter, HTML embed codes are generated, allowing to easily include Official.fm players in dynamically generated webpages. However, things tend to move more and more to the client side, and this means Javascript. Our Javascript binding allows you to do exactly that: access the Simple API from the browser, using asynchronous HTTP requests. But that’s not all there is to it.

It’s with great pleasure that we finally release our Javascript Player API. Creating players, manipulating them (play/pause/stop/next), responding to events (when reaching the end of a playlist, when paused by the user, etc.) has never been easier with this single javascript file. It is always up to date at our GitHub repo. Don’t host your own version but rather, use GitHub as a CDN, so that your web applications will never break even when we update the player.

Enough talk, time to get some action. Let’s get started with the Player API, since it’s the most exciting part of this release. In this example, I’ll just create a player for one of my favorite playlists lately, Sunset Melodies. First, we need an HTML page with an empty div, ready to host our player.

So there we have it, a nice skeleton page. Now we want to had a small bit of Javascript to actually create the player when the page is loaded.

In all our Javascript APIs, we use the global namespace OfficialFM. The most interesting method of the player API is, of course, create(). It takes a option hash allowing you to fine tune the player creation. Three fields are mandatory though: container_id, type, and id. Type is either ‘track’ or ‘playlist’, id is simply the Official.fm identifier of the track or playlist, and container_id, the id of the HTML element in which to put the player.

However, this simple example doesn’t do justice to the Player API. What we have ignored so far is that create() returns a Player object, with all sorts of interesting methods, such as play, pause, next, previous, get_current_track_info, etc. It gets better: you can react to player events such as onPlay, onPause, onProgress (called every few ms), onTracklistEnd, etc. For example, if you wanted to trigger the next player in a list, you would simply have to add these two fields to the options hash:

(To see it in practice, read this jsfiddle, featuring three tracks I really like.)

However, to obtain a list of track IDs, it would be even cooler to use the Official.fm Simple API, right? Well good news: there is a Javascript bindings for it. However, unlike the pure Player API, it depends on jQuery, so it’s a bit more heavyweight. Nevertheless, it makes it easy to build really nice applications. And to show my point, I have built a pretty HTML5/CSS3/Javascript application to show the latest tracks in a nice carousel: freshcove.rs. As usual, we’ve made the source available on Github, feel free to fork and improve!

Last time, we reviewed the Ruby bindings for Official.fm’s simple API. However, as we mentioned, we want to empower you, and that means giving you the choice of the language you want. Second of a whole series of language bindings, today we take a look at the PHP bindings which have just been released in version 0.0.1

As you have probably noticed, the Official.fm simple API responds with either XML or JSON. For the PHP bindings, we’ve opted for JSON responses, so the binding needs json_decode, present from PHP 5.2.0 and onwards. It also uses json_last_error if present, so if you have PHP >= 5.3.0 you get better error reports.

For maximum reliability, it also uses Sean Huber’s excellent curl binding for PHP, that you can grab here: https://github.com/shuber/curl. PHP’s new JSON module makes our API very straight-forward to use. Like the Ruby bindings, it is fully object-oriented. Here’s a really small example to get started with:

First, we include the officialfm.php. Since it depends on curl.php make sure that you have it in the same directory. Next, we instanciate the OfficialFM class, passing our API key. Next, we the profile of the user “nddrylliog” and print its full name. By the way, in production, replace this demo key by your own application key! It’s free, and it helps us respond to your needs in the best possible way.

To have a complete list of possible requests and their responses, have a look at our recently revamped developer docs. Note that, as in the Ruby binding, when you’re requesting information about a single element, the bindings will return a single object instead of an array, unlike the REST API.

Apart from that slight difference, you’ll find in the PHP API everything from the REST API, including the ability to generate embed codes for track players and playlist players. Here’s a small example to display the first three playlist for the search term “sunrise”:

Optional parameters, such as the maximum number of results and whether embed codes should be included in the response, are passed via an array as the last parameter to query functions. embed is an alias for api_embed_codes and limit is an alias for api_max_responses, like in the Ruby bindings.

Now let’s build something concrete with those PHP bindings. This time we’ll build something really trivial, a static Google map of an user subscribers/subscriptions and contacts. The Google Static Maps API V2 is insanely simple to use, basically we just have to construct the URL of the map’s generated image. The map can’t be scrolled, zoomed etc. like full-featured JS maps can, and we’re limited as to the number of markers because of maximum URL length that Google servers support, but we’ll focus on using the PHP bindings to retrieve Official.fm user information.

The core logic is really simple: creating an OfficialFM instance with our API key, doing three requests (subscribers, subscriptions, contacts), and iterating through them to construct our Google Maps URL. You can browse the full project’s source on Github, as usual, and see the result deployed on orchestra.io.

Next time, we’ll have an entirely Javascript-focused article, presenting a Simple API bindings and a new API which we are extremely proud of, and which will undoubtedly inspire many cool hacks. In other news, Music Hack Day Berlin was a blast! If you weren’t there, it’s official, you have been missing out. We’ll be kicking ass at Music Hack Day Barcelona as well, and although the registration is sold out, you should watch the hacks presentations, and follow @bcnmusichackday on Twitter!

It’s been a while since our Ruby gem was first released. Today we’re going to take a closer look at it by studying a practical example: ofmtweet. It’s a simple application that displays the last few tweeted tracks along with official.fm players. Besides being a great way to keep up with what’s being listened to on the Twitterverse, it’s actually a good example to get to know our Ruby bindings better!

Since it’s a small application, we are going to use the Sinatra web framework, with the DataMapper ORM, REXML to manipulate XML blocks, and of course the Twitter and Official.fm gems. We’re going to need a database to cache our results, since the combined requests to Twitter + Official.fm APIs make loading from scratch very costly. An in-memory SQLite instance will be more than enough.

Getting started

Here’s our Gemfile, run bundle install and you’re all set!

Your first step as an Official.fm application developer is to register your application in the developers zone. Don’t forget to give your application a meaningful name and description, along with a pretty logo — you don’t want to be unprepared when we pick your application to be featured on this blog!

Once you have your Application key, use it to complete this skeleton Sinatra app we’re going to flesh out:

To make sure we’re on the right path, run ruby app.rb and visit http://localhost:4567/ (or whatever port Sinatra is running on) to see the result.

Fetching tweets

This is not a Twitter API tutorial, but thankfully, the twitter gem is really easy to use. Good job, @jnunemaker! We’re going to be searching for tweets containing the string official.fm/tracks/. Since searching with the Twitter API is serious business, we need to create a Search object, specify that we want recent results (well duh), and say how many results we want. This is roughly what we’re looking at:

For a more complete example, see this gist which displays a pretty ugly list of tweets, but hey, it works.

Creating players

It’s easy to create an Official.FM player once we know the ID of the track we want to play. We use regular expressions to validate the track URLs and extract the track ID. We also ignore retweets, since they’re annoying, and we check for the presence of official.fm/tracks/, because the Twitter API searches in expanded short-urls, thus we’re going to end up with bit.ly, fb.me, jmp.

So what’s going on here? First, we create an OfficialFM::Client with our Application key. Then we retrieve information about a track, by ID, including embed codes, and we use the small embed codes in our list of tweets. The result is pretty neat, although at this point it’s obvious it needs a designer’s touch. See this gist for an example of players in the timeline.

The best way to see what’s happening behind the scenes it to play with our API Console. Here’s an example request made by our application. We could display a lot more infos such as the downloads count, creation date, genres, and a download link for some tracks.

Improving performance

If you’ve gotten this far, you might’ve noticed the application is running slow as fuck. Now the reason we have a database in the first place is because we want to cache those results. Instead of just caching the Twitter API results, we’re going to go one step further and cache the XHTML nodes we use to display the tweets in our application. This severely improves load times when the data is still fresh (<600s old, for the example). Since this is not a DataMapper tutorial, let me refer you to the ofmtweet repository, which contains the full database logic presented in this paragraph.

Another suboptimal detail in our implementation (besides the fact that Twitter’s public keyless API seems to take pleasure in waiting 3 secs before answering) is that one request per track is done in order to create a player. Not only is it wasteful and slow, it’s also unnecessary! Our upcoming JavaScript player API allows you to create Official.fm players on-the-fly, allowing a full dynamic experience. I’ve been dreaming of a minimalist HTML5+CSS3+JS unofficial front-end to Official.fm for ages now. Can you pull it off? I’d love to feature such an app on this blog.

See you next time for another language binding announcement!

It’s official: developers are first-class citizens here, starting now.

Let’s cut to the chase: this blog is here to keep you posted about everything API going on at official.fm. It will be updated regularly with news, examples, stats, and spotlights on projects we find particularly inspiring.

Our goal is to empower you, no matter which language or platform you choose.  Our job is to make your experience as smooth as possible, and to interface between you and our core development team so that your voice is heard. We love open source and we use open technologies everywhere in our products. Thus, all the API bindings are released under the New BSD License.

Here’s the current state of affairs.

The Simple API

The Simple API has been around for some time, allowing you to search for tracks, playlists and retrieve user information. Until recently it was simply a RESTful service, but we’re creating bindings so that it’s dead easy to use from major programming languages.

To use the Simple API, register your application and simply use your API key as shown in the various bindings examples.

Ruby

gem install officialfm

The officialfm gem was the first to be released. It’s currently in version 0.0.2, but there’s no reason the interface should change. It fully supports the Simple API, has unit tests and a complete rdoc. For a complete example application using it, see ofmtweet, a Sinatra web application that combines Twitter and the official.fm API to show the latest tracks that have been tweeted.

PHP

The PHP bindings, to be released very soon, are similar to the Ruby bindings. They also cover the Simple API and allow easy access to information about users, tracks and playlists.

Feedback

We’re still learning about your applications and how to make our API the most convenient possible. We’d love to hear your ideas for improvement and your bug reports! All our APIs and bindings have GitHub projects than you can report issues against. We’ll get back to you as soon as possible.

To stay tuned about API and binding updates, make sure to follow us on twitter. It’s also a good way to ask us short questions, as opposed to GitHub or our helpdesk, more suited for long-winded bug reports.

What’s next?

Player Javascript API

In addition to a full Simple API access, the Player Javascript API will allow you to create Flash or HTML official.fm players on-the-fly, from track or playlist IDs.

Advanced API

The Simple API was a first experiment with opening up our data to third-parties. But it was limited to read-only access. Our next step, the Advanced API, will allow write access, such as editing user details, voting, uploading tracks, and much more.

By the way, I’m Amos Wenger, Community Development Engineer at official.fm and my job is to be 100% dedicated to the developer community around our API.

Glad to have you on board !