Kudos to mAirList

In case you think from my earlier posts/questions that I don’t like mAirList–quite the opposite!

Apart from the real ‘big boys’ like BARRcode, WinRadio, etc., I think I’ve tried and tested almost every playout system on the market with the exception of Rivendell (Torben is anti-Microsoft, I am anti-Lin*x: so we are even!).

I have to say that in my opinion, mAirList compares VERY favourably with any other software this side of £1,000 (or €1,500 if you prefer!) and also compares VERY favourably with several systems I have tried which are even more expensive than that.

There are lots of things I love about mAirList:

  • it uses BASS engine, which I have found to be 100% reliable in the past.
  • you can configure the number of ‘main’ players (!).
  • players, cartwall, and PFL can be assigned to any sound card or set of outputs.
  • it has been written mainly for Live Assist rather than Automation, unlike most other playout systems I have tried.
  • uses INI file for configuration rather than Registry (though I suspect that at some future point, the 64KB INI file limit will be reached?).
  • can (allegedly) play files other than WAV and MP3 if you set up BASS to do that. (I have not managed to do this yet.)
  • it’s free to small NFP stations.
    and most importantly:
  • IT ALL WORKS! (You might be surprised to learn how many other playout systems’ ‘trial’ versions do NOT work 100%…!)

There are some things which I think could be improved:

  • no on-screen Stop and Play buttons on the players–VERY disconcerting when starting with mAirList! I’m still not sure whether ‘no buttons’ is a Good or Bad thing.
  • instructions to create on-the-fly database(s) (for those still baffled after reading the instructions, use the Config, go to Databases, then use the dropdown at top right and select On-The-Fly).
  • not sure that Cartwall is the best name for that feature: so many other systems use ‘cartwall’ to describe ‘all carts/items stored in the system, displayed in one big scrolling wall’ that I thought the mAirList Cartwall was the same, but the mAirList Cartwall is actually much more like a JazlerShow! cart ‘page’ which needs to be pre-loaded with files/items and ‘set up.’

And naturally, there are one or two things I hate about mAirList:

  • scripting has to be done in PASCAL (ack! ptui!)–a language I loathe.
  • does not support ‘native’ MDB/JET databases, only ‘add-on’ databases like mySQL, which IMHO make testing and evaluation an utter PITA and more difficult than it needs to be.

But in general, WELL DONE TORBEN for a brilliant product!

BFN
CAD

Cad.

I’m glad to hear that you like mAirList (at least, to some extend g), and I appreciate any hints for further improvement. As you might have noticed, user interaction is very important to me, and I like to hear all of your inspiring ideas, and I’m always happy when I’m able to implement any of these.

Oh, by the way:

* no on-screen Stop and Play buttons on the players--VERY disconcerting when starting with mAirList! I'm still not sure whether 'no buttons' is a Good or Bad thing.

Well - in general, I think they are bad. Because there are many better ways to control your players. For example, through remote fade start from your mixing desk. Or at least with hotkeys on your keyboard. But no radio professional would ever use the mouse to start or stop players, would he? Start/Stop buttons remind me of: software-based web “radio” broadcasting without a mixing desk; volume slides; talkover keys; … well, anything which might be a included in a number of so-called “radio automation” products, but would never be available in a professional playout system. And mAirList claims to be professional in a certain way.

On the other hand - and this is where your comment comes in - I admit that it is hard for the new user to learn and explore mAirList without these buttons. To speak for myself, I’m not a friend of reading manuals, I’d rather run the software and try it out. I see that this is hardly possible when you have to define hotkeys first, or if you don’t know about the keys predefined in the sample configuration file.

This is why I decided today that mAirList does need start/stop buttons. Of course, it should be possible to disable them, as any sophisticated user will easily get along without them. But they should be available, and they should be enabled by default when you first download and install mAirList.

These buttons will be available as of version 1.5.35. All of you old-stagers out there, go to the configuration dialog and disable them! :slight_smile:

* instructions to create on-the-fly database(s) (for those still baffled after reading the instructions, use the Config, go to Databases, then use the dropdown at top right and select On-The-Fly).

You are right. With the new AutoRescan and Cached options, the on-the-fly databases evolve as a nice thing everyone will want to set up for his local music collection. Instructions about this should be included in a “Quick start” section in the manual, for those who are tired of reading the whole configuration chapter.

* not sure that Cartwall is the best name for that feature: so many other systems use 'cartwall' to describe 'all carts/items stored in the system, displayed in one big scrolling wall' that I thought the mAirList Cartwall was the same, but the mAirList Cartwall is actually much more like a JazlerShow! cart 'page' which needs to be pre-loaded with files/items and 'set up.'

Interesting point. Well, I hope it’s not too confusing. Sometimes it’s hard to find the right terminlogy when you’re not a native English speaker. And when you’re one of the radio “newbies” (I started in 2000) who missed the golden times when the - literal - cart walls were still present in the studios :wink:

* scripting has to be done in PASCAL (ack! ptui!)--a language I loathe.

Well, mAirList is written in Delphi, which is Pascal. And I quite like that language.

The scripting interface is implemented with a product called RemObjects Pascal Script, which is very nice, because the “hard part” of writing a scripting engine is already done (parser, compiler, …), and you can easily import Delphi built-in functions as well as custom types and functions. Very nice for me.

Torben

Stop Start Buttons are a nice addition even though had quite warmed to starts from “F” commands.

When I started using mairlist it was confusing there being no stop start buttons but now happy without them so I’ve disabled the buttons in both players and cartwall.

Pause button had no use for me as once the audio is started it should play to the end.

The PFL button is useful for just that. though I cannot see why it should open the tag editor when used from one of the players remembering you cannot make changes here.

Cartwall I think is an apt description as I too date back to when radio studios had a stack of cart machines.

On The Fly Database is handy also, though I long to to see the future database function to replace radiodb etc.

I’m also keen to see the version 2 release of mairlist.

Can I politely suggest that the Repository is changed to be named either:

History (my favourite: same as HTML browsers, hence easy to explain to new mAirList users!)

or

Played Items (just in case History makes you go ‘aaagh NO!’).

Yes I do know that the Repository pane can be renamed, but it’s a pain to have to do this each time mAirList is started, because the ‘new’ name is not stored; also the menu item under the Add button in the Browser still says ‘Repository.’

I am happy to accept the preference for Cartwall as a name, but expect several confused new users because other playout apps. do use that term for all the ‘carts’ (that is, every audio file in the database!), displayed on a scrolling page similar to the Cartwall.

The context menu items in the Playlist pane for loading and saving a playlist should read ‘Load Playlist…’ (or ‘Open Playlist…’), and ‘Save Playlist…’ respectively. ‘This’ Playlist means the current Playlist in the pane, so ‘Open This Playlist’ makes no sense, yes?

Note there should be no spaces between the text and the ellipsis (…): this is a best practice for Windows Programs, unless you are deliberately breaking the Microsoft style guidelines? :wink: Also one of my pet hates in an application’s GUI is seeing spaces between the text and … in a menu!

To Tony: Sometimes a pause/stop is necessary, especially with rookie presenters. I accept what’s been said about ‘pro’ systems using some kind of ‘real’ remote, but trust me: we’ve run six successful RSL broadcasts of Leith FM (http://www.leithfm.co.uk) with variously unsuitable playout software, and yes Tony, we do start tracks with mouse clicks!

BFN
CAD

Cad,

thank you for your suggestions.

The term “History” is already used for the playlist-internal-history (the secret MaxHistoryCount setting, which is still undocumented, but will be officially introduced in v.36 - search the forum for details). But I’m fine with “Played Items”.

The word “this” in the playlist context menu refers to the fact that these open/save commands only apply to that very playlist (in case you have set up multiple playlists in the config), while the open/save commands from the toolbar will load and save all playlists as well as possibly the browsers, repository and cart assignments, according to your configuration. Maybe it’s confusing that the term “playlist” can refer to both the visual object on the screen as well as the content of that object. I didn’t find a better term for the visual object (internally, the class is called “PlaybackControl”, but this is not a good public identifier, I think).

Regarding the ellipsis: Intuitively, I disagree, because no spaces would imply that there are characters left out at the end of a word, while spaces suggest that there are words left out. And the latter seems to be the case. But, looking at the software installed on my computer, it seems that you’re right, and it’s - at least - best practice. But I didn’t know that there are people who would pay attention to this ,)

Torben

Though with the audio on pause it will resume from where you left off, far better to play the audio (if music) from start to finish, assuming all cue points are set.

Try setting mairlist with start stop functions and the autounload set to eject at end of file.

assuming all cue points are set
Bit of a rash assumption in our case! Nothing is tagged as yet.
Try setting mairlist with start stop functions
If you mean F1–F12 function keys, some of our presenters are allergic to using the keyboard to 'drive' the PC for playout, so require at least the option of deck buttons.
the autounload set to eject at end of file.
I already have it set up that way, but thanks for the idea! -- BFN CAD

On looking through the config options I had expected to be able to seperate the buttons that appear in the players.

Alas not, they are either on or off (in version 5.35 so things may have changed since then).

Instead it may be useful to be able to configure which buttons appear in the players allowing users to stop and start from a mouse click. The pause and pfl buttons that also appear in the players then used or not as the user decides.

Regards Tony

As of 1.5.41, you can activate the buttons separately. In some cases, the settings are not applied, but that bugs will be fixed in v.42.

Torben