Although it really seems like it’s the scripting that takes a while to open a script and process it.
I realise mAirList is very powerful having the scripting system that it does, however I wonder if some basic things like sound card mixer controls and serial communications shouldn’t be script based so they can be more time critical or more intergrated in to mAirLists more basic functionality?
I keep flicking between programmes and the gaps to achieve the same thing really makes me twitch at how long mAirList takes to run a script like a simple mixer control or serial string.
BTW, I’m not complaining even thought it may come across as it. I’m more just trying to express my testing with trying to make scripting work in a manner a few other systems accomplish much quicker or not as an external event like scripting therefore making the actions much more responsive (almost instant).
What I was wondering (with my programmer’s hat on) is whether you are still using the Notification (aka event-driven) type of scripting, or whether you have moved on to specific Action type scripts now?
Logically, event-driven scripts will probably have a slightly slower ‘reaction time’ than a simple ‘called’ script because internally, there is no event handler sitting waiting for something to happen, then figuring out what did just happen, then actually doing what it is supposed to do when something specific happens (if you see what I mean?).
In other words, if you are not doing so already, you should have a COMMAND in your Playlist which does a RUNSCRIPT, and the content of the MLS script it runs should be something like:begin
Mixer(1).Mute(0, 0);
ComPort(1).SendStr('AUTOMATION 1 NEXT'+#13#10);
end;
I would still recommend that you use the OnStartup procedure part of the Notification script, to be sure that the serial port parameters are set correctly each time mAirList starts up.
Maybe you are right about serial port comms. being somehow integrated into mAirList at a deeper level than scripting, but I can’t see how sound card mixer control could (easily) be more deeply integrated, since it’s such a messy business just to find out the correct Windows ‘numbers’ to control them!
I agree that some functionality, which is only available from scripts by now, should be integrated into the GUI. The mixer settings are a good example (given that I find out a way to determine the descriptions of each channel). However, I must admit that the scripting system is a good way to reduce my workload, as people can add the missing custom functionaly by writing a simple script
Thinking about “actions” associated with playlist items, the event scheduler comes into mind, where we have a very similar concept of actions. I will thus put the following on my to-do list:
Establish an internal “action” class, which covers anything you would like to do in a certain moment, pretty much like the “action” field in the event editor: add files to the playlist, run scripts, execute commands, mute the mixer ;), etc.
Replace the current “action” field in the event scheduler by an editable list of these new actions. This means that you can have more than one action associated with each event.
Finally, reuse these action lists plus the GUI from the event scheduler in the item properties dialog, allowing you to specify a list of actions to perform whenever the item is started and/or stopped.
It will take a little time, but I think it’s a good idea.
I use that exact code and call it from a playlist item when I need it.
I have moved the com port parameters to a start-up procedure script upon Torben’s earlier suggestion aswell however it doesn’t seem to make a noticeable difference. I’ve configured it like that anyway as it makes good logical sense to have the port open and ready before using it.
RE: The internal mixer control thing Cad. The best example of this I’ve seen was a system with a mixer that gave you a fixed number of virtual mixers internally (say 10 virtual mixers), then the user specifies which actual sound cards and channels those internal mixers should control. When unassigned, the virtual mixers just don’t do anything.
I thought about just using an audio file with a 19KHz tone for 40ms to use tone switching and signaling to a remote studio (filtered by an FM transmitter). Although that gave me a new set of issues. When I play such a short 40ms item, while the player goes to reload the next one almost seems to hang until the one that’s just played the 40ms file has reloaded. That might be my CPU power limited to 1.5GHz I’m not sure.
Either way rs232 makes more sense, more reliable, and can control an audio switcher for programme muting to a distribution bus (Internet Stream fed by master PC). This way I won’t need to mute anything at the remote studio end (slave PC) and not worry about split second programming when rejoining the network programme to prevent clicks and pops. The master PC will just send the first song down the line when it’s ready and if the master PC slightly overlaps the slave PC by a few milleseconds that’s fine, it’ll just sound nice and tight and gapless returning to the master PC programme.
If rs232 was looked at being optimised in mAirList, being able to customise the receive strings would be a bonus aswell. Instead of waiting for the command “AUTOMATION 1 NEXT” it would be nice if you could customise it to a shorter command to say “*1”. Just to make things quicker to send and receive/process.
Now I’ll go back and re-digest what Torben has written so I understand the programming logic behind the suggested changes to mAirList. Would this help remove the script processing delays?
I see what you mean about the action class in the event sceduler being quicker.
As soon as I hit enter on the - yes run this script manually box - within the event scheduler, the script process seems instant. Well, close enough to instantly.
Even with an action class type thing (time critical) handling of a script called from the playlist by a RUNSCRIPT command, how could you make sure the script has ran before continuing to the next event to soon?
On a side note (and if Charlie D is still reading this thread):
I’ve been keeping in touch with John Burnill who has done development on hardware processors and now doing software processors for FM radio in Charlie land (UK). The latest version he’s working on is intergrating rs232 bi-directional data with the option of a software STL processor (in it’s earlier days but a demo version is already released while still in development). It has a server/client streaming architechture for using TCP/IP between studios or transmission sites. Because the rs232 side of the STL code is in early development he’s including time coding in to the rs232 code to help calculate a perfect rs232 sync in the future. Since those AudioTX IP boxes are a bit of a pipe dream at the moment this sounds like it’s a good alternative, infact the only one with rs232 in a software STL.
Hey Torben, I think I might be on to something now, if not just imagining things but here goes, please read:
After mentioning the event scheduler is faster to launch a script (as in instant to my ears and eyes), and after mentioning on the side that if I have a 5ms audio item in the players, the next audio player doesn’t start immediately but waits for the previous player with 5ms to reload first… this might be the key to the runscript commands being delayed in the playlist. Why? here goes…
I did another experiment. After sucessfully making a script run instantly from the event scheduler with mAirList stopped, I decided to set a fixed time on a song in the playlist (not loaded in to a player with mAirList still stopped and waiting in Auto mode) to start smack on 2:30.00PM. I then set a script to run (mute the sound card) in the “event scheduler” for the exact same time, 2:30.00PM.
I was curious as to what would happen timing wise with the two things set to run at the same time. The result was, the playlist item (a song with a fixed time) was loaded and started while the script waiting to run from event scheduler was put on hold, for the exact same delayed 100ms or so that I had trying to run the script from a command in the playlist. So the audio started, before the script got the chance to run.
The key thing that jumps out at me, is that while a player is loading/reloading, this is when script processing is put on hold. Now I changed my CPU update speed in task manager to watch the cycles clock away during this load/reload process of the players. It hit just 30%. So I’ve got cycles to burn and from what I can tell, it’s not my CPU causing mAirList to pause its processes while it’s reloading a player.
This also happens as orginally mentioned, when starting a player straight after a runscript command in the playlist. However it seems the playlist is holding scripts until the players have stopped starting or reloading.
The scripts do not run in their own thread, but inside mAirList’s main thread, in order to avoid any synchronization/deadlock issues. Multithreading is a nice concept, but can be dangerous in the context of critical applications like radio automation systems.
But even then, the script execution should be atomic, i.e., mAirList should not do anything else but working the script, and loading of players etc. should be delayed until the script execution is finished. I will investigate this.
However, I have started to work on the above mentioned action system, and it should be partially functional in v.32. Perhaps it will be a better solution to your problem.
I have just uploaded version 2.1.32, which include the above mentioned “action lists”. See the Properties dialog, Option tab.
Note that when using the “send serial data” action, the COM port must be properly initialized beforehand, either by enabling it as a serial port remote in the main config, or by using a notification script which performs the initialization in the OnStartup procedure.
Hi Torben from the cold Southern hemisphere this morning.
Just downloaded it.
It works great! All I have to do is create a 40ms audio file with the attached actions to it.
I tried attaching a mute mixer action to an actual audio file with audio in it, however the audio started a little to quick again. So I’ll just use a blank audio file to attach the actions to which works just as good.
The reaction time using this new method is MUCH quicker than it used to be using commands to call scripts.
I did notice one thing as soon as mAirList started:
Access violation at address 00772DD2 in module ‘mAirList.exe’ Read of address 00000000
It is linked to the script I’m loading to call the playlist for the day which has stopped loading by yyyy-mm-dd format.
Other than that, so far it seems to run well. I’m out to visit a doc soon so will come back and do some more tests with getting the serial port and mixer muting exactly how I want :o)
procedure OnStartup;
begin
PlaybackControl(0).SetAutomation(true);
PlaybackControl(0).AutomationPlay;
CurrentPlaylist.LoadFromFile('c:\Program Files\mAirList\Playlist\' + FormatDateTime('yyyy-mm-dd', now) + '.mlp', false);
end;
procedure OnPlaylistEmpty(PlaybackControl: IPlaybackControl; Playlist: IPlaylist);
begin
Playlist.LoadFromFile('c:\program files\mAirList\playlist\songs.mlp', true);
end;
begin
end.
Found the problem. CurrentPlaylist causes this error when used from a notification script (where there is nothing like the “current” playback control from which the script was launched). It should rather return the first playlist.
You can use “Playlist(0)” instead until I release v.34.
Theoretically it shoud be possible, yes. But there remain several obstacles to challenge: What is the protocol like the display wants the data to be sent? Does the person programming own the exact same display to evaluate? Et cetera …
thanks for your reaction, Here is a link to the product i have: Link
it works on Port:COM3, Baud Rate: 9600
2 Lines of 20 Characters
With an another Automation software (SPL) i get info on it, but dont erease the old text,completelea by updating the text its shows up like: Mika - relax take it easyBillie eilish -
or its shows up not on the right way
With Mairlist its maybe possible to get more controle.
