|
Introduction Installation System Info menu Output formats
Cartchunk options
Lots more
Destination DirectoryRenaming files Playlist editor Files/Transfers |
Tools Menu Help Refresh Enable misc transfers Transfer queue |
Timed transfers Activity log Program updates
Automatic sysinfo backup Daylight saving time Manually transfer files Normalize audio levels Temp file cleanup Rev 1/26/2010 for 015x |
More information is available at www.amb-os.com. Telephone support is available at 1-877-AMBOS2U (1-877-262-6728). There is also a manual available in pdf format.
The Amb-os system delivers audio files to the receivers instead of "real-time" audio. The files are stored on the AMR-100's own hard disk, to be available to you when you need them. The receiver can also play them through its 2 stereo (or 4 mono) output ports. This gives you a great deal of versatility. Just some of the ways the receiver can be used are:
Play on air - The receiver can play files on its audio outputs directly to your main board according to your own schedule. Relays can be set to pulse or close and open when the file is playing. This is done by setting up a playlist with the Playlist editor. There is the potential for the receiver to handle all of your on-air needs for airing recorded programs. There are also trigger (relay) inputs to the receiver to synchronize the recorded audio with local or live audio.
File transfer - The user interface program can transfer files from the AMR-100's hard disk directly to your local disk, either when they become available, or according to your own schedule. The Rename files page allows you to rename the files to your own local naming convention, and to control when they will be transferred. For example, your automation system may be set up to play the same file every weekday, eg TheDaily.mp2. You can schedule this file to be over-written at a specific time each day, so each day you will be airing the current day's program. This would be similar to recording over a file every day from the former satellite feed. Only it happens when you want it to.
Play to record - You could also set up times for the receiver to play audio to be recorded by your automation system. It would be very much like recording a satellite feed, except you would control the "feed times" using the Playlist editor and would not be bound to the former satellite schedules.
When the user interface (UI) is run the first time, it will want to know the serial number (SN) and IP address of your receiver. You will want to give your receiver a static IP address if at all possible. Most routers like to assign IP addresses automatically with DHCP (dynamic IP address), but that will cause your receiver to get a new IP address after each power hit, so the UI will lose contact with it.
The UI will also need to know a destination directory for downloading the files from the receiver (unless you will not be transferring files, but rather playing them through the receiver's audio ports).
You can change this information at any time by selecting System info on the menu bar.
Also on the System info page is a choice for when updates are available for the executable program. The update is a quick, easy process that maintains your settings, so the default automatic update is suggested. But you can check "Ask me" if you want to be asked before the update is installed.
The Output format can be selected for the files copied to your computer's disk from the receiver (timed transfers and misc transfers). Options are:
Cart chunk options. The cart chunk is a section of a file with program information:
The Verify mp2 transfer feature will verify each mp2 file after is has been copied from the receiver. Every mp2 frame is checked to detect any file corruption. The transfer will be repeated up to three times, if bad frames are found. After the third attempt, the file will be used as-is (better a potentially small glitch than a completely missing file.
The Insert fmt chunk in mp2 will insert 3 chunks into an mp2 output file: bext, mext, and fmt, to conform to the BWF (broadcast wave format) spec. Some automation systems (eg Maestro) can import these mp2 files instead of having to convert them to wav. However, the ending may have to be .wav for these files, so use the Special file extension for this.
The Normalize to __ % will adjust the levels of wav output files. Enter a number up to 100. Amb-OS files are send at -6dBfs or 50%, so you can boost them up to full-scale, or wherever you want.
Prepend silence will insert 500ms of silence at the beginning of wav output files.
Temp folder allows you to select another folder to use for the temporary files that the UI creates during file transfer. The default is the system's TMP folder. You can use the Browse button to help select the folder. (For performance reasons, it should not be a network drive.)
The UI will clean out any Amb-os-format files in the temp folder that are more than 10 days old. This occurs when the UI first starts, and at the first periodic refresh after midnight each night (local time).
A backup copy of your system information is saved to your receiver whenever you change it. It is the equivalent of the export text file. Amb-os support can retrieve that file if you should ever need it. Soon (?) there will be a way for you to do it. Meantime, it is recommended that you save your own copy using the Import/export feature in the Tools menu.
As you enter file renaming info on the Rename files page, you can enter paths relative to this folder.
The files on the receiver will all look like this:
FOTF_FOF5_04-09-08_01-01.MP2
The first 4 characters describe the ministry, and the next 4 (after the
underscore) describe the program. Following that is the intended air date of the program (mm-dd-yy). Following that is the part or segment number and total number of parts or segments, ie 01-01 (as above) is a one-part file. 01-03 would be part one of a three-part program.
In the rename window, you will see:
Rcvr pattern - This is the part of the filename on the receiver that identifies the program. If the file is a multi-part file, you will also see a %p, indicating that you can use the %p or %1 variable in your local name to indicate the number of the part. Not using the %p or %1 variable in a multi-part program will cause all the parts to be combined into one file during the transfer process. (014t and later)
Local pattern - This is what you want the filename to be on your system. Do not use a file extension. this will be determined by the information you enter into the Output format choices in the System Info menu, either mp2 or wav, or another extension of your choosing. If left blank, the original (receiver's) filename will be used. If you enter an x in this field, the files for that program will not be transferred to your computer.
Your local filename can include several variables to be filled in based on the date in the filename on the receiver (letters can be upper or lower case):
Xfer time (day) - The time you would like the file to be transferred, with optional day offset. If this field is blank, the file will be transferred to your local system as soon as it is available on the receiver. If you specify a time, the file will be transferred each day at that time, if the file is available on the receiver at that time. The time should be h:mm (no seconds) using 24-hour time. You may follow the time with a space and a number indicating the number of days before (negative number) or after the air date to actually transfer the file.
If no day offset is entered, times between midnight (00:00) and noon (11:59) will be transferred on the same day as the air date. Eg, files with 04-09-08 in their name will be transferred on 4/9 at the time specified. The idea here is to transfer files in the wee hours of the morning to be aired that same day.
However, if no day offset is given, times between noon and midnight (12:00 - 23:59) will be transferred the evening before their air date (an automatic day offset of -1). The idea here is to transfer files the evening before their intended airings so they are ready to air, even at midnight of the "new day".
The idea behind the transfer times is to over-write the same local file each day. This would be analogous to recording a program from satellite at the same time each day and over-writing the local file with the next day's program. The good news is that you are not bound by the current real-time satellite schedule. You set your own schedule! It is suggested that you schedule the timed transfers somewhat close to your first airing, so that programs produced each evening will have the best opportunity to be on the receiver when your transfer time rolls around.
Above the Save button on the rename page is a choice to Make changes retroactive. If you want your changes to affect files already transferred from the receiver, (ie re-transfer the files already transferred) check this box. The changes will happen at the next Refresh. If you do not check the retroactive box, your choices will be applied to future files arriving on your receiver.
Sources window - Lists all the programs available on the receiver. It is taken from your baselist file, so it should contain all the programs you have permission for. They will have ##-##-## as the "date" since the current date will be substituted at playtime, so "today's" file will be played each day.
Double-click on a file to add it to the playlist. If you will be entering several entries for the same days of the week and/or playback channel or relay closures, you will want to make those selections before selecting the programs, since those selections will be added to each program you select. It's easier to set them up ahead of time than to change them all later on.
List individual files - The Sources window lists the templates for the files on the receiver (with ##-##-## for the date). But sometimes you want a specific file in the playlist with a specific date, eg a monthly promo file. Clicking List individual files will list all the files on the receiver for selection into your playlist. When clicked, the button changes to List file templates so clicking it again will again list the file templates.
Playlist window - Lists the files in your playlist, along with the playback parameters:
To edit an entry, click on it (once). Then enter the parameters for that entry. You can tab between the entry windows to save time. And the Enter key will save that entry and move you to the next. Or you can press the Save entry button.
The days the file will play are selected by the day boxes, and are displayed as "smtwtfs" for Sunday - Saturday. Days not selected for playback will be replaced with '-'. Eg, "-mtwtf-" is monday-friday. "-m-w-f-" is monday, wednesday, and friday. "s------" is sunday. Note the M-F box, which will check or uncheck all the mon-fri boxes, extending the life of your mouse by several stardates.
Hint: If you will be adding several files that will play on the same days (ie mon-fri) set the date boxes before selecting the files from the Sources window. That way you won't have to change them later.
The time needs to be 24-hour clock (00:00 - 23:59). You can use hh:mm or hh:mm:ss. If you want to play some files back-to-back, leave the time blank for all but the first one.
The day offset will adjust the date subsituted for the ##-##-## in the \file name. One use for this would be to play a weekend file on sunday. Most weekend programs carry a saturday date, they would not play on a sunday, since sunday's date would be substituted for the ##-##-##. So to play a saturday file on sunday, enter -1 for the day offset, so sunday's date will be adjusted back one day to find (and play) saturday's file.
Options for the output port are:
The relay parameter is optional. You can activate any one of the six relays, though relays 5 and 6 may be configured for use by the receiver, so check the configuration before using them. Select from the list (same options for each of the 6 relays):
You can also set an attenuation factor (db) which will be applied to all playlist selections. You can enter either a positive or negative number. Same difference.
Finally, hit Save playlist to write it to the receiver. It will take effect immediately. If a file is playing while you are editing, it will continue to play un-interrupted -- unless you change the entry for that file.
Cancel will close the window without changing the playlist.
You can also save the playlist to a text file on your disk with Write playlist to disk or retrieve a playlist you have saved with Read playlist into editor.
Status may be:
Of particular interest are the Misc transfers
These are files on the receiver for which a timed transfer has not been set on the Rename files page. It will also list files that are more than 24 hours past their transfer time. (Less than 24 hours, and they will be transferred as "LATE".)
These files will all be transferred if the Enable misc transfers box is checked. Note that if files are in the misc folder when the Enable box is checked, they will immediately be put in the transfer queue. In earlier versions, they would be transferred one at a time and you could stop their transfers at any time by un-checking the enable button. Now they are queued right away, and once in the queue, they are transferred in the processing of the queue.
Import will read the text file into the UI.
This is a text file, and you can edit it. However, be extremely careful. The import function expects all the data in the file to be correct.
Whenever you change your system information, the equivalent of an export file is automatically saved on your receiver. Should you ever need it, Amb-os support can retrieve this file for you.
Show approved files (Tools menu)
This will show the contents of a permission file on your receiver.
The date of the permission file is shown in the title bar of the permission window. A new file is sent whenever your permissions are changed, but an updated file can also be requested via email to programs@amb-os.com.
This page also serves as a cross-reference between the program designators and full names.
Log activity to a file (Tools menu)
You can save the entries in the Activity log window to a text file by clicking this menu item and selecting a file.
Current activity (if any) from the Activity log window will be written to the file, and all future activity will then be added as it occurs. (This means that closing a file and opening the same file again will cause the current activity to be written again into the file a second time.)
The file is always appended to, never over-written. The file name is displayed as part of the Activity log header to indicated that you are logging to the file. The filename is saved, so logging will begin again if the interface program is stopped and started.
The interface program keeps this file open, so you will not be able to rename it or delete it unless the user interface program turns loose of it. This can be accomplished by opening this menu item. When it asks you for a new file name, the previous file has been closed, and you can edit, rename, or delete it. Then you can select the same file as your new activity log file - or a new one, of course.
The log file does not copy the "rcvg" entries, since they are just of interest at the time the program is running, and not so much afterwards. The "rcvd" and "xfer" entries are written to the log, as well as the "began monitoring" messages.
The disk file will contain the date and time of each entry (mm/dd hh:mm) for easier reference later on. The on-screen activity log just shows time, in the interest of bvty (...that would be... brevity).
Refresh renames (Tools menu)
The local name for a file is determined when the file arrives on the receiver,
even though it may not be transfered until much later (by timed or manual transfer).
So sometimes the local names can get out of sync.
One way is by changing the local names on the
Rename files page
without making the changes retroactive.
This function will update any local names that should be changed.
Total refresh (Tools menu)
With rev 014g and later, the User interface keeps a list of programs in memory, along with their status. In this way, it knows which files it has transferred, and does not repeat transfers, even if the local file is deleted (ie from the "drop box" of an automation system). In earlier versions, the file list was created from scratch with every refresh - the receiver was listed, and compared with the files on the local disk. So files had to remain on the local disk for the UI to know it had transferred them. With the new process, the files list is kept between refreshes. It is also saved to disk when the UI quits, and read back into memory when it starts up. So the UI knows which files it has transferred, and when, so it can re-transfer any files that are re-transmitted over the satellite.
But if things get confused, or for any reason, you need the UI to re-build this list from scratch, you can do a "total refresh". You'll be warned that if your automation system has deleted files, they will be re-transferred.
Amb-OS Support functions (Tools menu)
These should be used when only directed by the Amb-OS support team.
Each one uploads a specified UI file to the receiver where it can be grabbed by the team,
or emails a file to support.
The reason you don't need this button (except to escape bordom) is that the system automatically refreshes when the program is started, when a file is received from the satellite, and every 10 minutes.
Speaking of 10-minute refreshes, you will see Next refresh on the main window followed by a time. That would indeed be the time of the next 10-minute refresh.
A bit below that, you'll also see a time which is updated every minute from the receiver.
Note that this is just the a "delta" refresh that looks for new files on the receiver. If you should need to start from scratch and totally rebuild the files list, see Total refresh in the Tools menu.
This setting will be saved when the UI is stopped, so when you start the UI up again, it will be set the same as it was before.
This has no effect on the Timed transfers, which happen all on their own.
The list can change at any refresh. If a new file has been received by the receiver that is subject to a timed transfer, it will be added to the list, perhaps even at the top of the list. The transfers are not enabled until the file to be transferred is on the receiver.
Timed transfers are set up on the Rename files page. This enables you to control the time that a local file will be over-written by a newer file. Eg, if you use a filename like focusdaily.mp2 for your automation system, and need it to be over-written each day with the new day's program, you would want to set up a transfer time for that file. For more information, see the Rename files page.
Files that arrive late (less than 24 hours after their transfer time) will be transferred as soon as they arrive. Also, if a file gets replaced by a newer file the newer file will be transferred. These will be logged as LATE or REPL in the activity log.
Timed transfers are affected by changes in daylight saving time. Timed transfers are scheduled using Windows system timers, which operate like kitchen timers. You set them for a certain amount of time, and then they "ding". For each file to be transfered, a timer is set when the file arrives on the receiver, so if a daylight saving time change occurs before the ding, it will be at the wrong (old) time. So the UI checks for timezone changes during its periodic refresh and, twice a year, adjusts the timers so they will ding at the right time according to the new time.
If you select to be asked, and you wait for more than 2 days to say yes, the update will happen automatically anyway to make sure everybody stays up to date with new features. Note that i did not say "and bug fixes". ... the very thought!
The help file updates will happen automatically, since it's just another file transfer.
Intermediate updates (with new features added) are also available from