Is this function for swapping items around in a playlist?
I tried mapping this to key 5 on the numeric pad. It’s mapped but doesn’t seem to do anything. I think I’m missing something here?
Thanks heaps again,
Gavin.
Hello!
First of all, you have to change x and y e.g. to 1 and 2 for Player A and B (use a editor for that, it isn’t possible with the config tool).
This command causes a changing of the elements locaded in these Players. So if a song of Madonna is loaded in Player A and Phil Collins is locaded in Player B, then they will switch - without changing an order in the playlist. So now is Madonna on B and Collins on A.
My Englisch skills are not very good, but I hope you understood it.
Greetz,
David
Thank you for your reply David.
I understand what you mean. I was thinking it was for a different purpose. I was hoping that I could swap items around in the playlist.
I’m trying to figure out how if possible I can move items in the playlist using keys instead of the mouse.
I’ve mapped the play/next function to the big numeric 0, cursor up and down to 8 and 2 respectively, ExtraPFL open/close to 9, test fade out to 6 and clear fade out to 3. I’ve mapped the break command to the “.” or “del” key. I was hoping to use button 5 in the middle of the cursor keys to “select” or swap items in the playlist with it so I can have all those functions on a seperate numeric keypad.
Gavin.
Hello.
I don’t have any idea how to implement this feature. I’m using the mouse. Maybe tw knows how to realise that 
Greetz,
David
Gavin, I’m not aware of any commands/actions which can move playlist elements around but there may be a way to do it using a script.
If that’s possible, and you have a script named SwapWithNext.mls, you could then assign THAT to a key using the command:RUNSCRIPT SwapWithNext.mlsNote that you would have to TYPE this command into the Config screen, or else edit the INI file manually.
Only solution I can think of, off the top of my head.
BFN
CAD
This is not possible, at least not at the moment, as the scripts cannot access the GUI.
the scripts cannot access the GUI.Oh. I thought one could access the Items in a Playlist by using Scripts. Therefore I thought it should (?) be possible to 'swap' elements in a Playlist using Scripts, and therefore the GUI would [i]reflect[/i] any changes made in that way.
Obviously I was wrong!
BFN
CAD
Well you can of course access the playlist and swap specific elements, but you will not know which element the cursor points on
Could there be a playlist.CurrentlySelected option or something added? That way you would know what is selected? Just a thought!
Well, that would be all to easy
What you see as a “playlist” in mAirList is internally made up of three objects, two of which are the so-called “control classes”:
- Playlist - holds the list of playlist items. Can be accessed from a script with CurrentPlaylist.
- PlaybackControl - reponsible for opening and closing players, managing the automation and the event scheduler etc. Accessible from the scripts with CurrentPlaybackControl.
The remaining object is the GUI:
- PlaybackTreeView - displays the content of a Playlist object and the state of the accompanying PlaybackControl.
The same thing is done with the players (“PlayerControl” and “Player”) and the cartwall (“CartwallControl” and “Cartwall”). The collection of all control objects belonging to one mAirList instance is called the “engine”. To get an idea of what each control class does, take a look at their methods listed in the scriping help file.
The separation of control classes and GUI is a common technique in software development. It offers a number of nice possibilities:
- mAirList could easily run without a GUI, as a background process on a server.
- The engine and the GUI could run on separate computers connected through the network. (Given a network protocol to pass the data between the two objects.)
- More than one GUI could be attached to one engine at the same time. For example, imagine a studio with two presenters facing each other. One could set up a mAirList instance with one engine but two GUIs, so that both presenters have their own monitor and see the playlist.
- The GUI objects can be easily replaced by different versions. For example, Michal, the blind user from Poland, would love to have a GUI which is built up of standard Windows controls only, so that his text-to-speech software can “translate” the GUI. This is not a big deal.
Most of these possibilities are not exploited yet, but will be needed for future developments.
So, what about the scripts now? They run inside the engine. And there’s no link from the engine to the GUI, only in the opposite direction. (Remember that in theory mAirList could run without GUI, or with more than one GUI.) I will consider to introduce such a link, without breaking the general concept of control/GUI separation.
Torben
OK then, Torben.
ISTM that it would be VERY handy for scripts to be able to ‘query’ the GUI and its controls (in a read-only way for the moment—perhaps later on, an ability to write to some carefully selected GUI controls might be desirable/possible).
So with my programming hat on… you would first need a means for a mAirList script to query whether the instance of mAirList the script ids running from does or does not have a GUI (and if so, how many GUIs?).
Assuming you have a ‘GUI class’ somewhere, the easiest way to implement that would seem to be to have a Public read-only property containing the count of the number of GUIs attached, so one could write (e.g.):var iGUICount, iSelectedIndex integer;
…
iGUICount := IMairlist.GUICount;
if (iGUICount > 0) then
{
iSelectedIndex := IMairlist.IGUI(0).PlaylistTreeview.SelectedItemIndex;
…
}
else
…
;(Sorry if that isn’t quite correct Pascal syntax, but as you know, I hate Pascal and prefer Visual BASIC!)
Is this suggestion broadly along the right lines for the way you have encapsulated your classes, Torben?
BFN
CAD
This is basically the way I would implement it, yes. Although I would prefer that each control object maintains a list of GUIs attached to it.
CurrentPlaybackControl.GetGUI(0).GetItemIndex(The GUI objects register themselves with the control classes anyway in order to receive notifies about any changes to the playlist etc., so the control object would only need to find out which of the attached clients are actually GUI objects.)
Which methods would you like to have? For example, for the playlist GUI object:
- Retrieve currently focused item.
- Move cursor up or down.
- Move cursor to a specific item.
What else?
Torben
My only question would be:
Does a PlaybackControl (I assume CurrentPlaybackControl is an instance of a PlaybackControl object? ) always have at least one ‘virtual’ GUI object?
If it doesn’t, then your syntax (which implicitly instantiates a possibly non-existent GUI object, remember!) could fail internally and throw an exception to the user.
This is why I suggested the approach which I put into psuedocode above. Generally speaking, it’s better programming to first establish whether a potentially non-existent object does actually exist before you try to implictly access it using a syntax like<object>.Get<object-which-may-not-exist>(n).<method>for example.
The alternative would be an ugly and unnecessary try…catch…finally around the statement containing the GetGUI(n), just in case there isn’t a GUI to, er, Get! 
Does that make sense?
BFN
CAD
Sure, it does. Of course, one should first check whether there is a GUI attached to the PlaybackControl object anyway (by calling “GetGUICount” or something). However, most people will run mAirList with exactly one GUI anyway
And yes, you are right, the IPlaybackControl interface returned by CurrentPlaybackControl is a reference to the PlaybackControl object concerned.
Torben