I have finally managed to prepare and upload another build.
Here’s three important things to notice:
I decided that there should be a public release soon. Unfortunately, mAirListDB is not finished yet (I’m a little stuck with the scheduler), so it will not be included in the public release, and it neither is in Build 514.
There’s a file named mAirList.jdbg which supersedes mAirList.map. It serves the same purpose but is in binary format and thus much smaller.
As mentioned earlier, there will be different editions of mAirList. The free one (for personal use) shall be known as “Community Edition”. A license.ini file will be included in the download, so I will not have to review all those license requests anymore. With that license files, a number of features (most notably BASSASIO output, for which I had to buy a license from un4seen) will be disabled. A copy of that license file is located in the beta download area. You will have to download it, mAirList won’t work with the old one, not even in demo mode. In case you wonder what else might be missing, you’ll find a complete list of enabled and disabled modules in mAirListConfig.
I will upload another license file which enables the missing modules as soon as I find the time to write myself a license file generator
Obviously no mAirListDB in this one so I can’t get a working DB going (still un-sure if you’ve 100% fixed the “couldn’t add everything” bug I found).
EditCartStack - window does not update “live” when dragging to it (nor does re-arranging, you have to close it and select EditStack again) - also, perhaps make the window sizable (and default to the last used size)
You’re right, mAirListDB is not included in Build 514. See comment #1 above. I consider making a first public release soon - not including the DB which is not yet finished. This is why its disabled in Build 514 which is some sort of “release candidate”.
Thanks for your feedback regarding the cart stack. The update issue is sorted out, and it will now also remember its size and position when you close and re-open it.
Yeah, I thought as much about the DB situation… I’m interested to find out how the scheduler will work and how it can be scheduled - Didn’t you say a while ago that you’ve never used any “proper” playout/automation software, and if so - does this include schedulers ?! I’m hoping that mAirListDB can import the User Attributes which will allow useful fields like Category, Gender, Style, Mood etc to be part of the scheduling attributes. Some form of “song card” system would make for an easy way of managing audio attributes (like a more detailed version of the Properties/PFL window).
I’m quite a fan of the grid-based system for setting-up Clock Hours - PSquared’s “AutoTrack” scheuduler uses this approach: The first few columns are required for each entry (start-time, category - for example) and the others (like Opener, Ending, Year etc) are optional. The advantage being that if you set your Jingles with similar attributes you can produce better sounding segues as the transitions match.
With SPL Creator, you can point your Song Categories to various folders but that causes a problem when you move stuff out of the A-List (usually a weekly event in CHR radio!) so you have to do it when you’re running a show/format that isn’t using those folders (for fear of getting load-errors in mAirList). The way I’ve been doing it is via MP3Tag - set all our fields via ID3 and then sort+export to an M3U based upon the values - Creator then just reads the file/path list so providing you don’t alter filenames, you’re OK.
Charlie, that’s exactly the point: I found that writing a scheduler - especially when it’s supposed to be a good one - is not at all trivial. This is why I will need your help (from all of you guys), and also some more time.
My current concept is:
The user can define an arbitrary number of so-called “hour templates”. This should be more or less what is called “rotations” in SPL Creator.
Each hour template consists of a list of items reflecting the number of items the playlist will later have.
Each item has a type and an optional set of rules.
The type determines where mAirList picks the item from: A random folder, a specific folder, or even a specific item (like a show opener).
The rules specify optional constraints to be satisfied: only items from the 1980s, only items with the “opener” attribute set etc.
The scheduler will then go through the list and find matching items.
That sounds quite good (from a user point of view), but you’re right - it’s a complex process of actually coding it!
I assume there will be Artist/Title protection, too We’ve used Natural Music in the past and that only offers Artist protection, so whilst you can limit how often the Rolling Stones turn up on the playlist, you cannot explicitly predict that Paint It Black with be most scheduled track - this is where Song Packeting comes in, a cluster of tracks from an artist… Elvis Presley and Queen are further examples of where a Packet would be preferable. Essentially, they ensure an even rotation of oldies from a given artist/group. Songs that fail the scheduling criteria can be kicked back to the bottom of the pile (or not).
I’d quite like to see a “type” that allows you to store popular mAirList Commands such as COMMAND, DUMMY or FIXTIME events. Dragging commonly-used events like “DJ BREAK” into the hour-templates would save having to type them every time
Some excellent night-time reading material can be found on Music1’s website courtesy of Steve Warren: http://www.gomusic1.com/Music_Scheduler/Essays/What__No_Software_/what__no_software_.html It’s a document that explains how to operate a computer-less scheduler in the radio studio using actual song cards in a box - some of it may be relevant to you when considering the scheduling routines.
If you need the help files from Natural Music or Powergold, let me know
Torben: Forgot to say earlier that if you want to discuss coding or if my n years of coding SQL queries would be of any use, I’d be very happy to discuss the ‘nuts and bolts’ of any specific problems you can’t solve on your own.
PS: Now you know why scheduling software is so expensive!
