Extend Action On… to more events?

[Cad]

LONG POSTING WARNING
I’ve thought this one through Torben, and it may be something you are already planning, but here goes…

I was messing with the Cartwall and realised that what I really needed to achieve what I wanted to do was the ability to have an Action for a Start Next cue point being reached (so I could ‘link play’ two cart players). This got me thinking, so I had a quick look at the MLP for a Playlist and realised that you could easily extend the idea of Actions (aka high-level event handlers) to allow pretty much any Player-related event to cause an Action. This would allow schedulers and automation producers incredible flexibility when prepping automated playouts, and you could do very natural-sounding voice-tracking by similar use of cue points and Actions.

This means the XMLDOM for a Playlist would change only minimally, with an extra container added to allow for new ‘Action event triggers,’ e.g. a Playlist’s XML would change from this:

... ... 1 CARTWALL 3 PLAY ... ...

to this:

... ... 1 CARTWALL 3 START ... CARTWALL 2 START ... ... ...

I would imagine the Options tab of a Playlist Item’s Properties dialog changing, so that the Actions part of the GUI would become something like a three-column Virtual Treeview, with the Action Trigger (e.g. On Start, On Play, On Fade, At Ramp 2, At Start Next, etc., etc.) in column zero; the Action Type (e.g. Execute Command, Enable Automation) in column one, and the Action Parameter (depending upon Action Type, this might be the number of the Playlist to be automated, a file name, etc.) in column two.

This also neatly allows for simple multiple sequential Actions (e.g. Stop Automation Playlist 2, Start Automation Playlist 1, Run load next hour script) for each Action Trigger; the simple rule being that multiple Actions for the same Action Trigger are run by mAirList in the order shown in the dialog. This means the grid/treeview would need the ability to move items up/down and/or drag/drop nodes in a tree, depending on how you would implement it. It’s like a short visible Action List for when you only want to do two or three ‘things’ when ‘something’ specific happens.

What do you think of this concept, Torben? I’ve striven to keep the changes as compatible as possible, but because of the structure change necessary to an MLP and its XML, there would need to be a conversion script to ‘correct’ existing MLPs/MLDs/MLCs which have Actions in them. Or maybe there would be no need because playlists are mostly ‘use once,’ except for the occasional MLT? Does anyone currently have a lot of Playlist files with Actions in them?

I really look forward to your comments on this one, Torben, and apologies for the long posting.

BFN
CAD

[Torben]

This is a nice idea to extend these actions. What are the “categories” you would like to attach them to? At the moment, we have “item is started” and “item is stopped”.

I agree that, when the number of “categories” starts to grow, it is favorable to move all of these lists into an additional node in the XML tree. Changing the XML file format is always an issue, but in most cases, I offer at least one version of mAirList which can still read the old and already write the new format. This version can then be used for conversion.

Are you aware that you can have more than one action per category at the moment? Just click the “Add” button multiple times

Regarding the GUI, I’d rather use tabbed pages, with one tab per category. I can then easily reuse the “edit action list” form, which is already used in several places: the Properties dialog, the Edit Event dialog, and on the Action Menu page in mAirListConfig. It’s always the same form, dynamically embedded into the parent forms.

[Cad]

@Torben

This is a nice idea to extend these actions. What are the “categories” you would like to attach them to? At the moment, we have “item is started” and “item is stopped”.

Thanks for the favourable reaction. 8) Logically, the complete set of ‘categories’ would be all the possible cue point names and all the possible Player-related commands (START, STOP, FADE, PAUSE, …). I hinted at this in my original message in the sample ‘new’ XML (hint: look for StartNext!).

@Torben

Are you aware that you can have more than one action per category at the moment? Just click the “Add” button multiple times

Yes thanks! But that list will not ‘fire’ when the item reaches its StartNext point for example, only when it STOPs.

@Torben

I’d rather use tabbed pages, with one tab per category.

Given the rather large number of possible categories (see above ;)), the dialog would be very messy if you default displaying one tab per possible category (!). I think you need to start with no category tabs (or perhaps just Start and Stop?), and a single ListBox control replacing the current ActionOnStart/Stop ListBoxes, which would have associated Add/Delete buttons to add/delete individual Action Category tabs (for want of a better name) to the main Item Properties dialog.

This ListBox would be labelled Action Categories and you might even want to have Start and Stop added by default to mimic the present dialog. Click Add… to present a ListBox dialog of all possible Action Categories, with an Add and Cancel button. Click Delete… to display a similar ListBox dialog containing all currently defined Action Categories, this time with a Delete and Cancel button.

Then on each Action Category tab (caption = "On "+, incidentally), you have your existing Action List form, working just as it does at present.

That seems to me to be the best way to handle it. I look forward to your further thoughts!

BFN
CAD

[Cad]

I was just thinking … now that we have ActionOnStop, do we still require Triggers in the Cartwall?

I realise that ActionOnStop doesn’t display a socking great TRIGGER in the Player, but it does allow a full action list (unlike a Trigger). It’s also much more consistent with the way Playlists and their Players work.

BFN
CAD

[Torben]

Good point. But I would need to introduce “Cartwall …” actions. Not a big deal.

I’m still not too sure about the GUI. I’ll get back to you once I start to work on these things.

[Cad]

@Torben

I would need to introduce “Cartwall …” actions.

??? But … these already exist! Right-click a Cartwall Player, click Properties…, Otopns tab, and the Action lists are already there. And the list(s) are saved when you save the MLC.

I know all this because I have used this method already, and it works well.

What you might want to do from now onwards is to ‘translate’ Triggers into Actions when saving MLCs. In a later version, (having warned all users to re-save all their MLCs!), you can remove the Triggers sub-menu from the Cartwall Player right-click menu.

BFN
CAD

[Torben]

Yes, you can attach action lists to cartwall items. But there are no actions for starting other cart players etc.

Of course you can use an “execute command” action and enter “CARTWALL 1 STOP”. But a “stop cart player #1” action would be much nicer, wouldn’t it?

[Cad]

@Torben

Of course you can use an “execute command” action and enter “CARTWALL 1 STOP”. But a “stop cart player #1” action would be much nicer, wouldn’t it?

Do we already have a specific (e.g.) ‘stop playlist 1 player 1’ Action? No. So it would be inconsistent to have (e.g.) a specific ‘stop cart player 1’ Action IMHO.

That said, I do understand what you mean. Users already using TRIGGER might find it over-complicated to rummage in the Execute Command list.

:-\ Tricky call, but I think I still prefer the ‘execute command’ method myself.

BFN
CAD