Fireplay is a company that mainly creates software for radio stations. I worked there part time for 4 years on several projects.

FirePlay OnAir

Every radio station needs to play music using some kind of player. FirePlay OnAir is much more than a music player but still makes playing music simple and easy. Main goal of FirePlay OnAir was to simplify all the tasks required to produce a radio programme.

FirePlay OnAir is written in C++ and runs on Windows. It mainly uses MFC for the overall architecture.  

Here are a few things I worked on inside FirePlay OnAir:

GUI engine

The old FirePlay OnAir, while functionaly very useful, needed an updated visual interface. My job was to create a skin engine that could make it easy to create and change the visual appearance of FirePlay OnAir. You can see the end result by looking at the main OnAir interface below. The engine was written in C++ using simple parsing of ".ini" like files. Many MFC controls were subclassed and made to use custom bitmaps. 

Audio caching

Since most radio stations have a separate file server where they store their music, it is a good idea to cache songs that will play soon.

To put it bluntly, I failed to create the caching mechanism and learned how hard multithreaded programming really is. Although everything seemed to work fine, there were times when songs that were cached just did not play correctly. Through this failure I began to explore why multithreaded programming is hard, and eventually ended up exploring a new programming language, Erlang .

FireOps

Before playing your music on FirePlay OnAir you have to plan your radio programme. FireOps makes it easy to create a schedule of things you want to play in OnAir. 

FireOps is written in C# and runs on Windows. It can publish the whole radio programme to FirePlay OnAir through a web service.

Working on FireOps I mainly learned the basics of C# GUI and database programming. The short experience with datasets, data adapters, and generated classes for manipulating them left me wondering if there was a better way to do all of it. What I found was a plethora of O/R mappers from NHibernate to Ruby's Active Record. This wasn't very satisfying but then I stumbled upon object oriented databases, about which I had hardly heard anything before. 

FireSave

To archive your radio programme you need something that records and stores it. FireSave allows you to save the entire 24 hour programme and play or export any portion of it later.

It was one of my first real life projects. The main thing I learned while working on FireSave were the basics of encoding and decoding audio, from enumerating audio devices to encoding and storing audio data in multiple formats.

Since FireSave has to work all the time I learned ( perhaps more than I wanted ) about intricate details of Windows services. Also I had to make FireSave a server that can answer queries about its status and manipulate recording quality on multiple channels.

There were ofcourse a few problems on the way. It had a bad habit of crashing unexpectedly without anyone noticing while still producing mostly empty audio files. Logs were not much help to debug it, however remote debugging did help. Most of the bugs were due to my inexperience with C++ and failing to grasp how hard multithreading really is.

FireLib / FireExplorer

While Fireplay OnAir plays music, FireLib makes it easy to find it in the database. Its alter ego, FireExplorer, simplifies finding music on a hard drive, shared drive or any other filesystem. 

Since finding music from the users stand point is basically the same whether you store music in a database or on the filesystem, it was decided that FireLib and FireExplorer should share as much code as possible. This requirement made me learn a great deal about software architecture. Coupled with the skin engine from OnAir, you coud just call the executable with a "/fireexplorer" or "/firelib" argument to get one or the other program.

The final product wasn't without its faults, but in the end it worked quite nicely. Mostly I learned basics of coping with a large amount of data ie. tables with thousands of songs referenced by many other tables with metadata. Doing simple joins in the database did not cut it anymore.

One of the interesting smaller things I worked on was making OnAir and FireLib share information. FireLib displays songs from the database. When you play a song in OnAir during a radio programme, you don't want to play it again for some time. My job was to display a small indicator above each song that tells you when the song was last played. Since OnAir does not access the database, I created a simple inter-process sharing mechanism using shared memory where OnAir tells FireLib it had played a song.

Fireplay setup

One of the easiest projects, but also one I had alot of fun with, was automating the install process for OnAir and FireLib. While there are many big setup generating frameworks like Installshield, or even the one that comes with Visual Studio, I chose simpler one from makers of Winamp called NSIS. It has a simple but powerful scripting language which sometimes almost resembles assembly (in a non scary way). 

Automatic build

Minor thing I created, with the goal of getting Fireplay closer to the Joel test, was a daily build script for my projects. It was a simple script written in Ruby that made sure it created a valid installation every night. It got all the source from subversion, built it, ran the nsis setup scripts and emailed back any problems it encountered.