YAY!
I managed to mute a sound card. This is what I typed up in the script:
begin
Mixer(1).Mute(0, 6);
end.
Just that and that alone. It worked! Depiste that mAirList only returned one mixer and it was called mixer “0: C-Media…” even though the script had to have mixer 1 assigned not 0. Anyway glad I didn’t give up.
Still no luck with a carriage return to the serial port though.
I’ve thought about sending audio from the main mAirList machine back through itself using a second sound card, so no external audio switcher required. Hence the bit about the sound card control above.
The delay is still quite a bit though. The audio comes through for about 600ms worth before the script closes the sound card. I would imagne when I do some serial serial testing the results will be similar.
It would be great if mAirList performed the order that the playlist was in IE: a command to run a script (then wait until command complete), then move on to the next event.
I guess this is how as you say Torben, the players and audio etc… happens first for the time being. Unless the scripts were loaded through the players even if they didn’t play? That way they go through the players queue without something else jumping in ahead of time, like the next event.
Gavin.
Got my carriage return and a line feed going out the serial port and learned something about programming along the way.
ComPort(1).SendStr('AUTOMATION 1 NEXT'+#13#10);I plonked the decimal values for the CR and LF on the end (which I just learned and now have on file) and the plus sign to have them included after the text string.
This is ideally what would happen for me…
mAirList starts the command that runs this script from the playlist ‘before’ the next audio item (say a 30 second promo) starts:
begin
Mixer(2).Mute(0, 6);
ComPort(1).SetParameters(115200, 8, 'N', 1);
ComPort(1).Open;
ComPort(1).SendStr('AUTOMATION 1 NEXT'+#13#10);
end.This mutes a second sound card which passes the first mAirList machine’s audio through to the second mAirList machine (or via Internet stream with the right hardware). When the second mAirList machine receives the serial string after the audio is muted it then starts it’s own playlist containing information and jingles to fit the duration of the same window. Then the following script is run on the first mAirList machine at the end of that break:
begin
Mixer(2).Unmute(0, 6);
end.Which returns the first mAirList machine’s programme to the second one or Internet stream with no left over 600ms large chunks of audio coming from the first machine at the break-out or break-in point.
Obviously the most important part still remains, eliminating any delay in muting/un-muting the second sound card, or sending of serial strings to an external switcher to switch off/on a studios programme mix.
For Charlie: Yes those AudioTX units are a bit of a pipe dream at that price. That’s why I’m surprised they never included rs232 in sync with their AudioTX Communicator software. I’m surprised no one’s bothered to write such a software encoder with in sync rs232 pass-through yet. I would consider it a very very valuable tool. I’ve seen other programmes around for using DTMF etc… but that means wasting a complete audio channel with independent stereo encoding in order to get the control signals through.
Gavin.
In the meantime, I have identified the reason for the delay. However, fixing it requires a major rework of the automation mechanisms. This however has to be done anyway in order to introduce the “start next” markers, so you can expect a solution in the near future.
Torben
Gavin,
sorry for leaving you alone with all this scripting stuff so far. I have been very busy this week, and haven’t been able to read all the posts in detail - otherwise, I could have saved you a lot of time, I think. Sorry for that.
As you have noticed - a script is nothing but a program, and writing a script is writing a program. So you do need some programming skills. Admittedly, some of the mAirListScript interfaces look rather complicated, and a very easy task might result in a complex (looking) script. But once you get to know the interfaces, you’ll be suprised what can be done with them.
In the meantime, I have started to work on the updated automation algorithms. I will also take a look at the simultaneous input/output of serial data.
Torben
I can’t help thinking (and I’m assuming that both of Gavin’s PCs are on the same LAN!) that it must be better/faster to send the commands etc. using RPC commands than using a much slower serial port?
Is there a sample (simple? 
) mAirListScript statement/method/function which can ‘send’ a command to a remote mAirList? Something like:SendRemoteCommand(netPCname-or-IPaddress,commandstring);
for example?
BFN
CAD
Hm, that sort of command is actually missing. Looks like noone ever needed it 
But you can use ExecuteCommand and issue an “RPC” command:
ExecuteCommand('RPC http://theothermachine:9300/BIN ' + commandstring);Torben
I’m sure a LAN is much faster as you say CAD. After all, 100Mbps vs 115.2Kbps is certainly much faster.
These are the main things I want to achieve that TCP/IP can’t.
1, to automate external rs232 broadcast device swtiching, such as an audio switcher. This is to mute the audio sent over an STL or Internet Stream to another station/studio while syndicating a show.
2, send another rs232 signal that gets encoded in sync along with the audio or over the STL to tell the station at the other end to start it’s playlist of items timed for the duration of silent breaks being offered. (I should have mentioned that the second mAirList machine won’t be side by side eventually, as it’ll be at another station handling their own break-out material).
3, send a serial command to un-mute an switcher to resume programming through the audio stream to the other station.
However in order to achieve that, it’s not the serial port speed that’s of big concern (so LAN speed doesn’t offer much difference), it’s getting those commands running from the playlist before the automation system decides to start the next audio event. At the moment, mAirList plays the first 600ms or thereabouts of the next audio item, before the command has been processed. This isn’t a problem with mAirList, it’s just not really ready for time critical scripting at present. Something Torben is very kindly looking in to.
I should have mentioned, ideally, the second mAirList PC is at another station being used for their own needs and inserting their own material, then they are able to hook up their audio decoding device’s rs232 port to mAirList and watch and act on network control signals coming down the line. That is the easy part and mAirList can already do it. If the second mAirList machine encounters a delay of 600ms of starting time it’s not so much of an issue, as the last item playing can be a local jingle if the network audio starts again with a song playing over the end of the jingle by 600ms.
The key issue, is muting audio and getting strings sent from the first mAirList PC to make sure there’s no audio present when it’s time for there to be silence going to the other studios. Rather than firing off the next event before this process is completed.
RS232 is also a good thing to have up an automation systems sleeve. It offers interfacing to satellite news receivers that hook up with rs232 to delivery start/stop cue’s and switch audio processor presets, transmitter settings with rs232 at remote sites etc… and more useful, network break out control signally for syndication etc…
Cheers,
Gavin.
edited: To tidy up my mess while writing this late last night.
Hi Torben.
Now that the Start Next markers have been added (which is coming in quite handy), any further joy with making serial data faster at being executed or should I say script execution happen before the next audio event?
Or is the current Start Next marker system still a temporary thing until your re-write of the automation handling happens?
Cheers,
Gavin.
New Zealand.
I guess we will need a new OnBeforePlayerStart event. I’ll put it on my to-do list.
Hi Torben, that was quick. In version .29 that is.
So my question this time, is what do I need to add to the code below in order to have this done before any other player starts with the new OnBeforePlayerStart function:
begin
Mixer(1).Mute(0, 0);
ComPort(1).SetParameters(115200, 8, 'N', 1);
ComPort(1).Open;
ComPort(1).SendStr('AUTOMATION 1 NEXT'+#13#10);
end.Thanks,
Gavin.
Create a copy of the “Notification Script Template.mls” file found in the “scripts\notification” folder, and paste your code into the “OnBeforePlayerStart” function. You can also move the initialization commands for the com port into the “OnStartup” function. Delete any other function which you don’t use, but do not delete the final “begin end.”:
[code]procedure OnStartup;
begin
ComPort(1).SetParameters(115200, 8, ‘N’, 1);
ComPort(1).Open;
end;
procedure OnBeforePlayerStart(PlayerControl: IPlayerControl; Item: IPlaylistItem);
begin
Mixer(1).Mute(0, 0);
ComPort(1).SendStr(‘AUTOMATION 1 NEXT’+#13#10);
end;
begin
end.[/code]
That’s it.
Won’t that run the same serial string before every single audio item? Or only when it’s called from a command in the playlist just the once?
I only want to send the serial string from a command in the playlist when I need to send specific strings at specific points in the playlist for audio switching and replacing material at another station momentarily. But I want this to happen in the order in which the playlist is, not the next audio item starting before the command has sent the serial string ;o)
I am probably misunderstanding the new OnBeforePlayerStart function, but it sounds like it’ll happen every time a player goes to start?
Cheers,
Gavin.
I managed to figure out the answers to my own questions with a little more playing.
It seems the onbeforeplayerstart procedure can not be called from the playlist through a command. Instead it has to load with mAirList on startup and therefore perform the same serial string every single time a player starts. Which would mean every time you start something, the other machine will start when I don’t want it to :o) So unfortunately that won’t work.
I only wish to send a serial string from the playlist when require, and have it sent or at least, the command in the playlist processed before the player starts.
The sound card is still muting after the next player has already started, meaning that a good chunk of audio makes it out of mAirList before it can run a script to send a serial string to an audio switcher. At the moment I’m just testing to make a sound card wave output mute instead, but not fast enough before the player starts.
Cheers,
Gavin.
Well I decided to create a 5ms audio file to put after my commands in the playlist to delay the start of the next audio item to AFTER the command/script is run.
This doesn’t work very optimally, but quite well. I’ve found that the players take 100ms or something to reload so I can just have a tiny 5ms audio file as the next event to happen in the playlist after a command.
This way I can get serial port strings out the serial port, or mute a sound card before the next audio item creeps through.
This still creates a good gap until the next audio item starts after being used to starting a wave file pretty much instantly, however it works.
Perhaps a onbeforeplayer start could be called from the same script within the playlist for a one off use, rather than at programme startup for continuous use. This would also save on a cluttered playlist with blank audio files in it.
Gavin.
I can add the ability to assign a script to each playlist item which is called whenever that item is started.
However please note that the 5ms delay might be very specific to your system and installation - other people might experience longer or shorter delays. So there will always be a little finetuning until you get real gapless playback.
Torben
The 5ms I found wasn’t really needed. I first started with a 200ms audio file of silence since it seemed to take 200ms for a command to process after the next audio file started.
Then I realised as I shortened the file more and more and stopped at 5ms, that it wasn’t the length of the audio file that I had to worry about. The reload time of the player was enough.
However I hear what you’re saying, that it will be faster or slower depending on what system spec’s are.
That sounds like a good idea, having a script attached to an audio file. That way I could just have an audio file such as “Network BreakOut” to drag in to the playlist without having to worry about typing in a command all the time to run a script :o) Then I could just set the startnext marker depending on the delay needed to run the script.
Cheers,
Gavin.
Actually not just great, infact it would be awesome. Then I could launch the audio item with script attached in assist mode aswell? ;o)
Gavin.
I’ve been following this thread for a while and I’m a bit confused now!
Probably I am missing something really obvious (to Gavin ), but why does he not simply use a ‘run this script’ COMMAND in his Playlist when he wants to do his thing with the serial command?
If I understand Gavin correctly, what he needs is to be able to start automation on a remote mAirList PC, yes? Presumably at that point he will want to stop automation on the ‘master’ PC, only re-starting when the ‘slave’ PC has finished running its list. Is that right or wrong?
If it’s ‘right,’ then this is the same ‘problem’ as having one Playlist start another, then ‘wait’ until Playlist #2 has finshed before re-starting (which I implement using COMMANDs in the two Playlists). I use that technique for handling ad. breaks, where Playlist #2 has Events which load the ad. playlists about 5 to 10 minutes before they are due. Is that anything like what Gavin is trying to achieve with his scripts? If so, then the only difference is that the start/stop automation commands are going via serial ports and hence need to be ‘sent’ using scripts instead of COMMANDs. So your COMMANDs would be RUNSCRIPT instead of direct Start/Stop Automation commands.
BFN
CAD
Hi Cad.
I am using scripts, from a command, called from the playlist as needed. I have just shortened what I was orginally talking about down to commands to send serial strings in recent posts.
Yes you are correct I am just sending serial strings by running a script from a command in a playlist. The only thing I have an issue with is the delay from those scripts executing while the next audio player starts unwanted until the script has had a chance to do anything.
The master PC however will still be playing audio, it won’t stop. The slave PC will be substituting material and the audio from the master PC is muted either by a second internal sound card (loopthrough) or by an external switcher controlled by serial.
To me, rs232 timing is important in radio. As there’s satellite news feeds, external audio switching etc… involved in a lot of automation these days even in live assist with networked or spot substituted stations on the net. Calling serial commands via scripting in mAirList just seems to include some delay compared to what I’m used to in the past.
It’s not just in serial strings my orginal delay problem comes up. If a command in my playlist only calls a script to mute a sound card channel, the next audio player has already started in mAirList before the script has muted the sound card. This is not desirable for externally automating. It means 100ms of audio or clicks and pops coming from the master PC before the audio is muted to the slave PC.
rs232 and time critical processing of commands and other automation events is what makes an automation system either easy or difficuilt to automate or interface to other equipment. It’s also something that makes a radio playout system very flexible outside of the PC in a studio.
Gavin.
edit: What Torben has suggested would certainly tidy up my playlist of commands and silence audio files to counter act this issue. It would make it as easy as dragging and dropping and audio item to the playlist, which also means it’s loaded by a player so you can quickly see it’s a next to play item aswell, which the commands currently don’t offer via the players . Hopefully also it means automating scripts in assist mode by being attached to audio. As I’d like to have scripts run in assist mode aswell, otherwise I need to use auto for scripting in what would normally be an assist mode environment.