mAirList 2.1 preview


I’m very busy preparing the new development branch mAirList 2.1. However, I had to make significant changes to the source code, and some parts are not working at the moment, so it might take a few days until I can offer the first version for download.

The good news: I have already started to implement some cool new features. You can read about them in the Wiki:



Very nice - I look expectant forward to this new edition of mAirList. Additionally I have a question concering the feature “Shoutcast/Icecast Stream Relaying”. So is it possible to create an automation that plays a shoutcast or icecast stream for a few minutes and after that the tool continues with the playlist?



Yes, you will be able to manually specify a duration for the stream. It will then behave like a file of the same duration. If you don’t specify a duration, the stream will just play forever.

Hmm… those seem like very weird features.

I don’t like the idea of a ‘tree-like’ Playlist; I like the Playlist looking the way it is in V2.0!

Will that Extra PFL Player tab in Properties be configurable, to either Hide or Remove it? I definitely do not want presenters to be able to screw up my carefully-placed cue points by ‘playing about’ with an Extra PFL player in Properties!

I’m puzzled by the ‘render an audio file from a Playlist’ feature. That sounds like a feature for ‘club DJ’ software, not professional radio automation software?

What’s next? Waveform displays and ‘visualisations’? (PLEASE GOD NO!!!)


CAD’s comments regarding presenters changing settings reminds me of a question I had but never got around to posting.

What do you need to do to stop ‘presenters’ altering settings that they should not? Is there an ‘admin’ level? If not how do you stop people fiddling?

From my brief experiments, mAirList seems to restore default settings when run - if this is correct then is it a case of protecting the ini files through XP folder security settings or similar?

Come on, Cad, stay calm. I’m sure many users will find these features useful. And if you don’t, you don’t have to use them, do you?

The “allow Extra PFL” setting in the config will of course be respected. If you switch it of, there will be not PFL tab. Just like before.

I know many people from German community radios who prepare their show as a sequence of music and voice tracks, and then record the automated playlist, send the audio file to the station.
(Most German states don’t allow community radios to do live broadcasting, every show must be pre-produced.) The ability to render the playlist will be useful to these people. Of course, it’s not an essential feature for an automation software, but at least a neat gimmick.

Some background on the playlist: The component I am using now (Virtual Treeview) is much more flexible than the native Delphi components, including TDrawGrid, which is used in mAirList 2.0. For example, it allows resizable columns, drag & drop between multiple mAirList instances and so on.

In principle, Virtual Treeview provides a tree view with multiple colums. That is, if you use a flat item hierarchy (only one level of nodes without any childs), the “tree view” will look rather like “list view” or “grid”. At first, I will make the new “Playlist Treeview” look exactly like the old v2.0 grid. Then, we can think about how to take advantage of all of the features of Virtual Treeview. One idea is that, if you have specified a comment on a playlist item, to create a child nodes containing that comment. Then the user can decide which comments to show or not to show by expanding or collapsing the node. This is more flexible than the current global “show comments” option. Of course, you can still make all comments visible at the same time by expanding the full tree.

By the way, the same component is already used in various places in mAirList 2.0: In the Event Scheduler, the browser (all of the directory/database browser windows are descendants of Virtual Treeview), … The playlist is the final piece of the puzzle.

Ron, you’re right, all of the settings are stored in the ini file, which is only read by the main program, but never altered or rewritten. If you protect mAirList.ini (and possibly skin.ini and/or layout.ini), your presenters will not be able to make any permanent changes to the config.


Hi Torben, busy as ever.

Just wondered on the time scale for new database and scheduling?

Kind Regards Tony

Come on, Cad, stay calm. I'm sure many users will find these features useful. And if you don't, you don't have to use them, do you?
Having read the rest of your reply, I'm reassured. My original reaction was posted from work, on a day when I had problems installing Bank remote access software on one of our accountants' PCs! :) So apologies if I was 'over the top.'
I know many people from German community radios who … record the automated playlist, send the audio file to the station.
Interesting: obviously I didn't know that. I guess they must use voicetracking? I've only ever done pre-records 'as live' with a live mic. and not voice tracks. My voice tracks always end up sounding like ad. voiceovers… :) So yes, recording a Playlist isn't as 'odd' as it originally appeared to me, and I now support that one.
The component I am using now (Virtual Treeview)
I found the Virtual Treeview Gallery at [url][/url] and again, I understand now. (Incidentally, Torben, maybe you should submit a 'plug' for mAirList to that page? It [i]is[/i] a Virtual Treeview app., after all!) It was there that I also discovered a rather cute freeware XML editor called XMLEdit2 (downloadable from [url][/url]). Just the tool for anyone wanting to 'explore' mAirList data files like MLP, MLE, etc.!

So, apologies again, I’m much more ‘chilled’ today. :slight_smile:


What do you need to do to stop 'presenters' altering settings that they should not? Is there an 'admin' level? If not how do you stop people fiddling?
Ideally, you would have a 'studio' PC and a 'production' PC, with slightly different mAirList configurations on both. The production PC would for example allow saving cue points to MMD files, etc., which would NOT be allowed on your 'on-air' PC.

I’ve pretty much completed documenting all the Configuration options in the Wiki now, so I hope you have all the info. you need to plan something like that. I suggest you print out the Configuration Options page and sitting down with a coffee (or whatever!) while you note which settings you want ‘on,’ and on which machine.

As Torben said, you can (and probably should) make all the INI files in the mAirList program folder on the playout machine read-only, and possibly apply Windows security to them (if you have a network with different user ID for presenters, etc.).


So apologies if I was 'over the top.'

Never mind.

Interesting: obviously I didn't know that. I guess they must use voicetracking?

I guess, most people still record “as live”, which is certainly preferable. I’m not a big fan of voicetracking either, but I think there might be situations where the render feature comes in handy. It’s at least a nice little, fancy feature, and it was fun to implement; with the current class hierarchy and interfaces structure, it wasn’t much work at all, and it approved the efforts I put into establishing these interfaces.

Submitting mAirList to the Virtual Treeview gallery is a nice idea. I will do so once v2.2 is ready (which will then be the first stable release with VT used for the playlist).