I don’t know if it’s in your mAirlist roadmap, but I think it should : if you could find a way for scripts to access to “Gui Event”, and especially the current selected playlist item, scripts will not meet limits ever !
Lots of scripts ideas are blocked because of this limitation (thanks MVC pattern :D). I don’t imagine all the very important features/bugs you’re working on. But, allowing users to write scripts that can find which item is selected into the playlist will give us lot of fun for writing some very good and useful scripts !!!
After that, we could more easily wait for testing all the future features ^^.
Every new statement in mAirListScript has to be implemented by Torben. This is a limitation of the PascalScript language which mAirListScript is based on, rather than any Micropsoft limitation.
So, I wouldn’t hold your breath for thread control.
It’s actually a Delphi limitation (non-thread-safe VCL) that prevents full access to the GUI from (threaded) scripts.
Perhaps we can make a list of things that would be useful to access from a script, and I can check if I can implement a backdoor for them.
(Another problem is that - in theory - more than one GUI can be attached to a control instance auf mAirList, but we better ignore that problem for a while, I suppose.)
I don’t ask “full access” to gui event, because I understand very well the problem.
But, I think it’s possible to gice some “basics” information that allow developers to find the selected item. For example, a method that give the index of the current selected item. If PFL player is able to rely on the selected item, I think delphi code put the information in some “space” somewhere…
In my mind, this feature (I only speak about “current selecte item”) is very important because it opens lot of doors for future mAirlist Scripts.
Well, of course this information (e.g. the currently selected item) is stored somewhere (in RAM). But due to the missing thread-safety, you’re not allowed to read it from a background thread, because it might be in any inconsistent state as you access it.
The most simple solution is to copy the required information (e.g. the index of the selected item) to another, thread-safe location whenever it changes (when the selection changes). We just need to find a good place for that copy that fits into mAirList’s overall architecture.
As mentioned earlier, mAirList follows the MVC pattern. In particular, the control classes and the GUI are two separate parts of the code that communicate through messages. The interesting point is that there can be multiple GUIs connected to the same control core at the same time, pretty much like a client-server-architecture. This possibility isn’t exploited at the time being, there’s only one GUI. But it would be very easy to open two mAirList main windows (say, for two presenters) that visualize and control the same instance. So when your script wants to know which item is currently selected, which of the two GUIs is it talking about?
You might argue that I’m making things more complicated than they are (after all, right now there’s only a single GUI), but I always prefer to find a solution that will continue to work in the future.
Perhaps some script (run from the Action Menu) that performs some operation on the currently selected item, just like setting a particular color, adjusting cue points or so.
[quote=“Cad, post:7, topic:6749”]I still can’t think of any USEFUL script that would require ‘knowing’ which item in a Playlist is currently the ‘selected’ item.
Can you give me an example of a ‘fun and useful script’ that WOULD require this information?
BFN
CAD[/quote]
Mmmm, you would like to hear the next mix… without segue-editor, if we have access to the selected item, we could imagine to hear the segue mix.
Moreover, you would like to navigate to next items after the current one, you have to know where the current cursor is…
By clicking on a button, you would like to load the current selected item into any players (for specific live needs like I will introduce you later), you have to know where the current cursor is.
Imagine a world where mouse are not use (or not often)… You should do all your actions by touching touchscreen, or use a specific keyboard… Knowing the current selected item will help you to manage all the actions you could operate.
And just believe me ! Many radio stations have a mouse, but it’s not handy to use it when you’re on air ^^
Try this: select two adjacent tracks (Ctrl+select), then right-click the Playlist and click Selection PFL. On the Selection PFL dialog, drag the progress bar to the point where the tracks segue (note the cute way the Title in the player changes: nice one, Torben!) and you will hear the segue as it will occur on-air. 8)
To edit the segue, you would have to close the dialog, then PFL the first track (only) and change its Fade Out cue point value. Which I agree is not a full-blown segue editor, but is still better than nothing for now.
Hmm … good point! But the current item is always highlighted, so you can use the ‘down-arrow, up-arrow’ trick to move the highlight down/up, and thus force the grid control to auto-scroll to display what was the original selected item.
Maybe there is a case for:
Being able to specify scroll bar ‘magnification,’ so the scroll bar could more easily be operated by a touch screen?
Adding GUI actions to the available Actions, so you could have an Action of PLAYLIST 1 SELECTEDITEM LOADINTOPLAYER or PLAYLIST 1 SCROLLTO SELECTEDITEM?
Actually … it would be nice to have a +/- option on SELECTEDITEM so you could for example have SELECTEDITEM+1, and also an optional player number at the end so you could then say: PLAYLIST 1 SELECTEDITEM+1 LOADINTOPLAYER 3
So I guess the full syntax for both suggested Actions would be: PLAYLIST n SELECTEDITEM[+|-n] LOADINTOPLAYER [n] PLAYLIST n SCROLLTO SELECTEDITEM[+|-n]
(or something like that!).
You could then add that Action as an Action menu item if you wanted to, or assign it to a button.
8)
A commercial UK radio station used to use touchscreens until the day one of their cleaners wiped a touchscreen with her duster and played who-knows-how-many tracks simultaneously live on air. : Standard non-touchscreen monitors re-appeared in all the studio areas very soon afterwards.
I agree that custom keyboards (like Tipro) with a custom button layout and function is the best way to go. Obviously (?) you still need a mouse available.
Try this: select two adjacent tracks (Ctrl+select), then right-click the Playlist and click Selection PFL. On the Selection PFL dialog, drag the progress bar to the point where the tracks segue (note the cute way the Title in the player changes: nice one, Torben!) and you will hear the segue as it will occur on-air. 8)
.
