One purpose of this blog is to give you a little background information on the development of mAirList, talk about things which could be done or will be done, and initiate some discussion about the future of this software. This is what the new category “Future and Research” is for, and you are welcome to leave your comments.

As mentioned earlier in the forum, one of the prominent (although not too visible) features of mAirList 3 is that it is very modular. First, we have this set of modules you can see in mAirListConfig, each of which can be enabled or disabled depending on your license file. This makes it very easy to offer different editions of mAirList, as I now do. These modules, along with the components which make up the GUI of mAirList, can easily be put together to build a new software. In this article, I will show you a small example which gives you an idea of the consequences of this ultra-modularity.

Imagine you’re the manager of a big syndicated station network, and you have just discovered the potential of internet radio. You have a large music archive with thousands of files, and also some spare licenses for your music scheduling software. So why not start, say, ten music-only internet radio stations, each with a different kind of music? Rock, soul, country, etc.

Of course, you want a powerful automation software to operate these stations which broadcasts directly into your Shoutcast or Icecast server. mAirList 3 (with the integrated streaming encoder) would be a good choice. But for an automation-only station to be set up quickly, mAirList is packed with too many features, isn’t it?

QuickStation main windowThis where QuickStation comes into play, a new software I’ve been working on. It is based on mAirList, which means that 99% of its code, both the non-visual components and part of the GUI, have been reused to build this new software. If you consider mAirList a set of building blocks, then QuickStation is the same set of blocks, only put together in a different way.

The main window of the application looks rather simple: There’s a list of stations currently being managed along with their status (playing or not) and encoder status (connected or disconnected),and there are buttons to add, remove or restart a station. If you look closely, you will notice that the station (or “instance”) is simply identified by a folder name – this is where all configuration files, playlist, etc. are stored.

A QuickStation instanceDouble clicking a station brings up the instance management dialog. (Of course, the station continues to run and broadcast even if the dialog is hidden or closed.) On the first page, there’s the playlist and some detailed information about the song which is currently playing, along with some start/stop/next buttons and a peakmeter. The “loudspeaker” button in the lower right corner toggles the local audio output. If it’s off, the output will only be sent to the encoder but you won’t hear anything on your local PC. This is a very convenient feature when you have more than one station running ;)

For the technically minded, the playlist is implemented by using an ordinary mAirList playlist component running in automation mode. It offers the same features as found in mAirList, e.g. stream playback, fixed times etc. It is assigned a single player (but no player GUI object as found in mAirList, so it’s a hidden player). The start/stop/next buttons work exactly like the corresponding buttons in the mAirList GUI. The peakmeter is the same one as used in the Encoder Status screen object in mAirList 3.0.1.

There are no screenshots for the other pages of that dialog yet, but it’s easy to see what they will offer:

  • On the “Events” page, there’s an embedded event scheduler window, the same one as found in mAirList, and also with the same functionality (events and actions).
  • The “Encoder” page lets you manage the encoder settings, and displays statistics (e.g. listener history).
  • The “Log” page contains an embedded system log window, the same as displayed in mAirList 3 when you double-click the bottom status bar.

For your convenience, the content of the playlist and the events will be saved instantly as you change them, and will be restored when you restart the application. During shutdown, QuickStation will also save the current playback position of all instances and resume playback at the exact position as the playback resumes.

There will be some other convenient features which make the setup and management of the instances very easy. For example, when you set up a new instance, QuickStation will create a set of events which will load hourly or daily playlists from a pre-defined folder (inside the instance configuration folder). There’s no need to do that manually anymore. Just let your music scheduling software save the playlists into that folder. QuickStation will find and use them. Integration with mAirListDB (or any other database offering scheduled playlists, e.g. eldoDB or radioDB) will also be possible, as well as using any of the logging facitilies found in mAirList.

Other features to be considered are a Linux command line version for use on servers, a web interface, or a remote control feature interacting with mAirList for easier handoffs.

I think this will be an interesting piece of software for anyone running a (constantly changing) set of automated stations looking for a replacement for sc_trans and the like.

The software is not ready for release. For the moment, please consider it a case study. Of course, I’m looking forward to hearing your comments and ideas.