SPL APE tags to MMD..

English General
41

… and three more item types I just thought of which should be included:

News
(any pre-recorded news item: could be a whoile bulletin or just a single story)

Show
(an entire pre-recorded show, or ‘programme’ if you prefer)

Package
(any pre-recorded ‘bit’ which is part of a show: could be e.g. news of this week’s gigs in town, horoscopes, an interview, current local traffic news, whatever!)

BFN
CAD

42

Any news here? I really miss the items mentioned above…

43

Sorry, I was busy with other improvements :wink:

Perhaps you can give me a hand by compiling a list of types from all the suggestions in the posts above, then I can just copy it into the source code tommorrow or so.

44

No problem! :slight_smile:

Here is the list - together with some suggestions for the german translations:

sounds - Geräusche sound effects - Soundeffekte trail - Vorschau promo - Promo sponsorship - Patronat sweeper/liner - Sweeper bed - Musikbett Instrumental - instrumental News - Nachrichten Show - Sendung package – Rubrik (?)

45

Thank you. Very helpful, although I did not quite agree with some of your translations :wink:

I’m uploading Build 661, please check if there is anything missing.

46

If we expand the category “jingle” to use such detailed terms like sweeper or promo we should also add the following terms:

transition
sounder
opener
outro
bumper
stinger

BTW: An option to mass tag files in mAirListDB would be very, very helpful!

47

As mentioned earlier, a complete mass-tagging facility isn’t so easy to implement. But I will make it possible to change the type of an item (or multiple items) by dragging onto the respective node of the library tree.

48

Nice, that would be very helpful!

Three other necessary types came to my mind:

information
header
theme

It would be very nice if you could add them to the next snapshot. :slight_smile:

49

Information? Header? Theme? What’s that supposed to say?

50

[ul][li]Information is the type of a dummy. For example “top of the hour” or “place moderation here”.[/li]

[li]Header (normally a dummy; similar to information) is the topic for a following block of jingles.

Example in a playlist:

NEWS (header)
News opener (jingle)
Separator 1 (jingle)
Separator 2 (jingle)
Separator 3 (jingle)
Weather opening (jingle)
END OF NEWS (header)
[/li]

[li]Theme is another sub-category of jingle. It is used for elements like the “Simpson’s theme” or the theme of “Derrick”.[/li][/ul]

51

Then it should rather be a special playlist item class and not a type. As it makes no sense to have a file with type “information”, does it?

52

On the one yes - on the other hand no. :slight_smile: If somebody creates different dummies for different situations in his database, it would be useful if one could browse them under the type-node. But if you don’t understand this, I don’t mind. The items mentioned above plus ‘theme’ are much more important.

53

[quote=“@gent 001, post:46, topic:6395”]If we expand the category “jingle” to use such detailed terms like sweeper or promo we should also add the following terms:

transition
sounder
opener
outro
bumper
stinger[/quote]

We could keep going with this forever: every station has their own names for things like this. What you call '‘headers,’ I would call ‘intro’ and ‘outro!’

Although sweepers are jingles, promos aren’t. Promos are a subset of Ads (or Commercials as Torben insists on calling them :-), and have the specific meaning of ads. for a station’s own events; as opposed to Trailers, which are ads. for upcoming shows. The only reason I suggested sweepers as a separate category is because they can be played out OVER a track, unlike (say) a sung jingle.

I think jingle and sweeper would be enough. The main reason for this is to make things ‘selectable’ in mAirListDB for the purpose of creating hourly playlists. If you really need sub-categories like ‘intro,’ ‘outro,’ ‘bumper,’ etc. then I think what you should do is call them all Jingles in the item type, then create folders in mAirListDB named ‘intro,’ ‘outro,’ ‘bumper,’ etc. That way, it prevents the item type list growing to a silly length AND means you can still select (say) a header or a bumper when generating your playlists.

Also, I’d say what you call ‘information’ is a DUMMY item. And ‘theme’ is a sub-category of Music (not jingles), so again I think that if you want this, you should add it as a user folder and not have it as a type. Instrumental is justified as a separate type, because you could use any instrumental as a music bed, and also it alerts the presenter not to expect a vocal to start any time soon. :smiley:

BTW: An option to mass tag files in mAirListDB would be very, [u]very[/u] helpful!

Surely the way to do this would be to ‘mass tag’ the files via MMD, using one of Charlie Davy’s auto-tagging scripts, then if necessary, delete and re-import the tracks into mAirListDB? That would then ‘pick up’ the item types etc. from their MMD files.

BFN
CAD

54
Ads (or Commercials as Torben insists on calling them Unentschlossen)

Look at the latest snapshot, it’s “Advertising” now.

55

I’ve been watching this one with interest - I agree with Cad that we can talk “item types” until x>infinity and what I consider “standard” isn’t necessarily what anybody else would. My own little project is using the following: ADVERT, AUTOMATION COMMAND, JINGLE, PREREC, PROMO, SONG and VOICETRACK - those are the internal types which the program knows how to handle - sub-styles of those are up to the user (Sweeper, Dry, PSA, DJkickoff etc).

One way a fairly popular system handles these is to offer the user a table of (say, 20) fields which can be filled in ad-hoc. This list is then offered in a combobox (drop-down to our non-programmers!) and either sorted A-Z or not depending upon how clever the writer wants to be. This approach has some drawbacks but also some benefits - Perhaps there can be a set amount of mAirList-style names that the software handles in a special way (sweepers and voicetracks being obvious examples) but also allow user-defined types to be added later.

My personal choice would be a bare minimum list of primary item types and then secondary properties can be user-defined. Thoughts ?

Oh, and I like the APE to MMD util - my own “MyLibrary” program is doing the reverse :wink:

56

A fixed list has several advantages regarding implementation and later use. Let’s just agree on a “reasonable” amount of items, and everyone will be ok.

57

Thanks. I’ve been meaning to add an option to add an icon and/or set a colour when you scan a folder/files etc. Just need some time a four-month old to stop teething :slight_smile: