To: All Concerned Fr: On Air USA Dt: 27 February 2002 Re: UDS II environmental variables The purpose of this document is to encapsulate information about UDS II environmental variables into one textfile. References in this document to "ENV" mean "environmental variable". An environmental variable is a convenient way to cause a program, such as the UDS II, to behave differently based upon the setting of that variable. In most cases, an "ENV" is a "set once and forget" operation. In all cases, it allows runtime behavior to be modified without the added overhead of an interactive configuration menu or picklist (such as found in the UDS II's F8 window). In all cases, an "ENV" persists only in RAM (in a region reserved for "the environment") and is destroyed after a reboot. Resultantly, it is customary to set an "ENV" in the AUTOEXEC.BAT file located in the C:\ directory. This means those variables will be re-established with each reboot of the computer. (Perhaps the best known of an environmental variable is the one that sets the "PATH"). The default value of the environment's size is 256 bytes. If, after addition of "ENVs", the message "environment too large" appears, the user should add the /E:nnnn (where nnnn is a number in bytes) option to the SHELL= line in CONFIG.SYS to "upsize" the environment. 27 February 2002 ---------------- On behalf of client WZRU in Roanoke Rapids, NC, Ed Dravecky has demonstrated an additional value for DCS_HALT_PRIOR (and its equivalent, RSHD_HALT_PRIOR). * This new value is 9 (with 8 being reserved for possible future use). It is available as of UDS II version 2.35k. In short terms, setting either DCS_HALT_PRIOR or RSHD_HALT_PRIOR to a value of 9 is "sure kill" of the prior non-music digital audio item. This means that regardless of the next source...and regardless of what triggers the segue, there will be no overlap of audio. * Refer to the section below designated with II, which contains documentation of all digital audio-related ENV user-configurable parameters. 21 January 2002 --------------- As of version 00.27a of the RS-HD's ``oad-main'' application, a change made in the QUEUE CART response has an impact on the behavior of the RSHD_CUT_INFO environmental variable. * Refer to the section below designated with II, which contains documentation of all digital audio-related ENV user-configurable parameters. In short terms, all non-music (MOHD) carts will now have the cut number revealed even if there is only one cut (or "subcart") associated with the cart. 14 December 2001 ---------------- As of version 2.34z of the UDS II (DPMI or otherwise), the range of allowable IRQs and addreses for UDS II's "Primary" and "Secondary" serial devices has been expanded to encompass the entire spectrum. * The following environmental variables are impacted by this modification: ENV Description --- ----------- UDS2_RS232_IRQ Primary serial IRQ UDS2_RS232_ADR Primary serial port address UDS2_RS232_2ND_IRQ Secondary serial IRQ UDS2_RS232_2ND_ADR Secondary serial port address 1). For either device, the allowable IRQs are: 3 4 5 9 10 11 12 13 15 2). For either device, the allowable port addresses are: $2E8 $2F8 $3E8 $3F8 Also be sure to consult the notes in this document for section IV, which summarizes all of the hardware-related ENVs. Given that a number of serial devices can be used by the UDS II, it is imperative that the IRQ and port addresses don't conflict with other UDS II devices. Furthermore, measures must be taken to avoid possible device contention with external hardware such as a modem or a mouse. 19 November 2001 ---------------- Throughout this document, reference is made to setting environmental variables in the C:\AUTOEXEC.BAT file. On a DOS-based system hosting the UDS II, that is the preferred place to set these ENVs so that the values persists across reboots. - However, if using a DPMI flavor of the UDS II on a Windows platform, the preferred location for UDS II-specific environmental variables is C:\UDS2\UDS2CONF.BAT. This fully-annonated file is run just prior to launching the UDS II binary, canonically C:\UDS2\UDS2.EXE, by one of three PIF files supplied with UDS II when it detected a Windows platform. 13 November 2001 ---------------- As of version 2.34u of the UDS II (DPMI versions only), the environmental variable, UDS2_OAD_MIXER, was changed from a boolean to one permitting a range of values. As of this date and UDS II version, the allowable range is either 1 or 2. - If set to a value of 1, RS-422 commands that are intended to manipulate an audio mixer (such as the A-4000 or SM-05) are instead redirected out the RS-232 serial port where they are eligible for the control of sound card levels. When set to 1, an RS-422 card is still expected to be present, affording the ability to manipulate relays and respond to contact closures. * When UDS2_OAD_MIXER is set to a value of 1 in the environment, the following informative entries are written to the current DIALOG and UDS2BOOT.LOG files: "OAD_MIXER = 1: RS-422 mixer control disabled" "OAD_MIXER = 1: relays and contact closures enabled" - Likewise, if set to a value of 2, RS-422 commands that are intended to manipulate an audio mixer (such as the A-4000 or SM-05) are instead redirected out the RS-232 serial port where they are eligible for the control of sound card levels. However, when set to 2, an RS-422 card is NOT expected to be present. Consequently, the UDS II has no ability to either manipulate relays nor is it capable of responding to contact closures. * When UDS2_OAD_MIXER is set to a value of 2 in the environment, the following informational lines are written to the current DIALOG and UDS2BOOT.LOG files: "OAD_MIXER = 2: RS-422 mixer control disabled" "OAD_MIXER = 2: relays and contact closures disabled" 13 October 2001 --------------- As of version 2.34m of the UDS II (DPMI versions only), there is support for a boolean environmental variable, UDS2_OAD_MIXER. - If set to a value of 1, RS-422 commands that are intended to manipulate an audio mixer (such as the A-4000 or SM-05) are instead redirected out the RS-232 serial port where they are eligible for the control of sound card levels. 11 October 2001 --------------- Throughout this document, there are references to environmental variables with the prefix of ``DCS_''. An example of such is ``DCS_SS_FADE''. Note that, at the preference of the user, such environmental variables may use ``RSHD_'' as a prefix rather than ``DCS_''. Note that "RSHD_" in this context does not have a dash. - In the case of DCS_SS_FADE, the name would then become RSHD_SS_FADE. 10 July 2001 ------------ As of UDS II version 2.33s, a new environmental variable was added for a specific type of RBDS encoder, the Inovonics Radio Data Encoder Model 711. * The means by which to configure a UDS II system to support this encoder is to set the following in the environment: UDS2_RBDS=INOVONICS_711 * Note that the value is case-sensitive, requiring use of uppercase. Also, the underscore is required prior to the "711" designation. Refer to the notes in section III. below for additional details on this and other RBDS-related environmental variables. 26 June 2001 ------------ A new environmental variable is supported for all five types of RBDS units available to the UDS II: UDS2_RBDS_SPEED Refer to the notes in section III. below for additional details on this and other RBDS-related environmental variables. 11 June 2001 ------------ - As of version 2.33eN, currently an internal release version, a new value may be used for UDS2_RBDS: STREAMAUDIO Note that the value is case sensitive and is used without any form of punctuation or separator between the characters spelling the word. Although the StreamAudio system (intended for use by Cox Broadcasting in Miami) is not technically an RBDS utilization, it is still classifed as RBDS-like for the purpose of this document. As a consequence, refer to section III. below for additional details on this and other RBDS-related environmental variables. 7 June 2001 ----------- Note that environmental variables can be considered as "key/value" pairs with the string to the left of the assignment operator serving as the KEY and the string to the right as the VALUE, viz., KEY=VALUE 1). There must be no whitespace on either side of the assignment operator (equal sign). 2). There must be no trailing whitespace after the VALUE. This aspect is a bit difficult to track down since trailing whitespace is very hard to spot in most editors. One technique to find it is to locate the end of the line. If the cursor lands in a region beyond the VALUE, there may be whitespace. If the "vi" editor can be used on the file providing UDS II enviromental variable key/values, use the ":%list" command which will unambiguously show any stray whitespace in the file. 3). The KEY portion of an environmental variable is NOT case sensitive. Convention, inherited from MS-DOS, is to use all uppercase letters for the KEY portion. Although not required, adherence to this custom is strongly recommended. 4). On the other hand, the VALUE portion _is_ case sensitive, unless otherwise noted. For example: UDS2_RBDS=ASCII [Correct] uds2_RBDS=ASCII [Correct, not recommended] UDS2_RBDS=Ascii [Incorrect, value not "ASCII"] 8 March 2001 ------------ While on site at WVRU in Radford, VA performing an upgrade to RS-HD/UDS II, Ed Dravecky posed the following question via e-mail: > One point of confusion on my end: The UDS2.!!! files clearly shows > that environmental variables such as UDS2_8255_ADR and UDS2_RS232_ADR i > should be set to values like "380" but the UDS2_ENV.TXT files shows > values like "$380" just as clearly. Which is correct? (Are both > correct in this context?) Both are correct. The ``$'' symbol is used (in a Pascalian sense) to explictly state that the value is hexadecimal. However, it can be dropped since the UDS II's internal parser recognizes that the value is going to be hexadecimal, with of without the leading currency symbol. Consequently, either of the following yield the identical results: UDS2_8255_ADR=380 UDS2_8255_ADR=$380 - This optional eliding of the leading ``$'' applies to any environmental variable using a hexadecimal value. 26 October 2000 --------------- As of version 2.31c of the UDS II, IRQ 5 was added to the list of allowed values for UDS2_RS232_3RD_IRQ. Consequently, the complete list of valid values is: 3 4 5 9 10 11 12 13 15 Remember that there is no default value. 24 October 2000 --------------- As of version 2.30y of the UDS II, the following environmental variable may optionally be used to force the system to associate a utility relay with a simple network record enable command -- even when the UDS II is configured with a serially-controlled external switcher, currently one of the 6x1 or the 10x1 units from Broadcast Tools. This is a boolean ENV and must be set to a value of 1 for it to be in effect. UDS2_RECORDING_RELAY When set to a value of 1, a system command on source 80 imported via a breaknote such as the following will cause relay #2 to fire in spite of serial control of the switcher being available: ^80 [2] {REC0} Refer to the notes in section IV of this document for more details regarding the syntax of this environmental variable. 20 October 2000 --------------- As of version 2.30q of the UDS II, the following environmental variable is supported to enable serial control of an external Broadcast Tools Switcher/Router (currently either the 6x1 or the 10x1). UDS2_SWITCHER - The value must be set to one of BT6X1 or BT10X1. Refer to section IV in this document for additional information and further details. * Note that there is a mutual relationship between all three of these recently introduced ENVs: UDS2_SWITCHER UDS2_RS232_3RD_IRQ UDS2_RS232_3RD_ADR Every one of them must be set to a valid value in order to enable serial control of one of the two aforementioned Broadcast Tools Switcher/Routers. 19 October 2000 --------------- As of version 2.30n of the UDS II, the following two environmental variables are supported: UDS2_RS232_3RD_IRQ UDS2_RS232_3RD_ADR The support for these is limited to a DPMI flavor of the UDS II and is intended, as of this writing, for serial control of a Broadcast Tools Switcher/Router. Because control of a Broadcast Tools Switcher/Router is currently the sole purpose of this RS-232 serial communications link, the baud rate is fixed at 2400 BPS. The "3RD" in the name of the ENV is intended to clearly convey that it is for the parameters of the UDS II's notion of a third instance of serial port, not necessarily COM3 nor even the third use of serial port from the end user's standpoint. * The name "3RD" was chosen since it is generic, thus extensible for possible uses of a serial port for communications of devices other than the immediate needs of controlling the Broadcast Tools Switcher/Router. - For instance, in an RS-HD only setting, the first serial port (COM1) may be used to control the Broadcast Tools Switcher/Router and the second serial port (COM2) may be used to comunicate with the RS-HD. In such a scenario, the settings, for example, would be as follows: UDS2_RS232_IRQ=3 (COM2 -> RS-HD) UDS2_RS232_ADR=$2F8 UDS2_RS232_3RD_IRQ=4 (COM1 -> BT Switcher/Router) UDS2_RS232_3RD_ADR=$3F8 NOTE: There are no default values defined for either the IRQ or the port address. The user must explicitly set both of these values in order for the third instance of an RS-232 serial communications link to become active. Furthermore, it is the user's reponsbility to ensure that the selection of an IRQ and address does not conflict with any other device, such as another serial port or a network adapter. 16 October 2000 --------------- ============================================================== In order to take advantage of this enhancment, the user must be operating a system with UDS II version 2.30i (or greater) along with RS-HD version 00.12f (or greater). ============================================================== The maximum allowed value of UDS2_HD_BAUD is now 115200 as of version 2.30i of the UDS II. This is applicable only for an RS-HD RS-232 serial connection to RS-HD version 00.12f or greater. The default speed remains at 38400 unless overridden by setting this ENV. Also see the notes dated 9 October 2000 in this document. 9 October 2000 -------------- ============================================================== In order to take advantage of this enhancment, the user must be operating a system with UDS II version 2.30g (or greater) along with RS-HD version 00.11t (or greater). ============================================================== The maximum allowed value of UDS2_HD_BAUD is now 57600 as of version 2.30g of the UDS II. This is applicable only for an RS-HD RS-232 serial connection to RS-HD version 00.11t or greater. The default speed remains at 38400 unless overridden by setting this ENV. 26 September 2000 ----------------- Support for a newly-added environmental variable is present in yet-to-be-released UDS II version 2.29l. This requires that an RS-HD unit be in use as a digital audio server, which implies that this ENV is supported only by DPMI flavors of the software. The basic syntax is as follows: RSHD_TIME_SYNC= - or - RSHD_TIME_SYNC=FALSE|NO|OFF The user can tune this ENV to govern how the UDS II will attempt to synchronize its notion of the current time of day relative to the RS-HD/Linux box. Refer to section II below for additional details on this and other RS-HD-related environmental variables. 7 August 2000 ------------- Support for an environmental variable, "UDS2_EAS_SOURCE", is now available as of version 2.28e of the UDS II. This ENV uses a pair of values to determine the EAS source and the contact closure pin to insert the EAS source. Refer to the notes in section VI of this document for more details regarding the syntax of this environmental variable. 19 June 2000 ------------ This document was spell-checked today. In addition, its syntax was also scanned and the content validated for correctness. 9 June 2000 ----------- As of version 2.26a of the UDS II, the following two environmental variables are supported: UDS2_RS232_2ND_IRQ UDS2_RS232_2ND_ADR The support for these is limited to a DPMI flavor of the UDS II with dual digital audio support of both a DCS and RS-HD. The "2ND" in the name of the ENV is intended to clearly convey that it is for the parameters of the second serial port. Given a UDS II dual digital audio system, with both DCS and RS-HD: - The primary serial port is reserved for RS-HD. By default, it operates, at a speed of 38400 BPS on COM1 (IRQ4 0x3F8). Because of its speed, a 16550AFN buffered UART is required. These two ENVs can be tuned to select another port: UDS2_RS232_IRQ and UDS2_RS232_ADR. Refer to the notes in Section IV, below pertaining to "hardware-related ENVs" for more details on what values are permitted. The baud rate is configurable by adjusting the value of UDS2_HD_BAUD. - Given a "Dual DigAudio" configuration, the second serial port is reserved for DCS. By default, it is mapped to COM2 (IRQ3 2F8) at a speed of 2400 BPS. Although a buffered UART is very highly recommended, it is not an absolute necessity given the slower speed and lower volume of traffic between the DCS and UDS II. Finding anything other than a 16650AFN in the current era will be difficult, fortunately. The parameters on the second serial port can be changed as explained in Section IV, below. Note that the baud rate is fixed at 2400 and cannot be changed. Since the only purpose for the second serial port is for DCS communications, there's no need to change the speed to anything other than 2400. * In most cases, though, the defaults will be precisely what is desired. 20 March 2000 ------------- The following boolean environmental variable is available only with DPMI-enabled UDS II systems, version 2.24c or greater: UDS2_TIME_COMP_LOG Setting this causes the UDS II to log verbose diagnostic information to the DIALOG file when a time compare segue occurs. Refer to Section VI below for more information on this and a variety of other environmental variables. 15 March 2000 ------------- This document was updated to explicitly state that the voice track feature is also available with the RS-HD as well as the DCS. In addition, corrections were made in the description to clarify that the "ramp up" of audio occurs when the EOF (not to be confused with the EOM or "AUX mark") is detected. 13 March 2000 ------------- The following boolean environmental variable is available only with UDS II systems, version 2.23m or greater, equipped with RS-HD version 00.05t or greater: RSHD_CUT_INFO Setting this causes the UDS II to "reveal" the cut numbers for RS-HD sourced non-music carts. Refer to section II below for additional details on this and other RS-HD-related environmental variables. 18 February 2000 ---------------- 1). As of version 2.22w of the UDS II, the following new environmental variables are optionally available (only in the DPMI flavor of the software). Setting any of these instantiates the special enhanced EOM handling feature of UDS II. UDS2_PIN2_EOM UDS2_PIN3_EOM UDS2_PIN4_EOM UDS2_PIN5_EOM Refer to the description in Section VI below for more details. 2). As of version 2.22v of the UDS II, a new environmental variable, HD_CATASTROPHIC_REF, determines whether failure to load ("queue") a cart will increment the "catastrophic" failure counter. Read more about this (and other hard drive related) variables in section II, below. 28 December 1999 ---------------- Starting with version 00.02d of the UDS II (equipped with RS-HD, which implies a DPMI flavor), there's support for the following boolean environmental variable: RSHD_IGNORE_STOP_SIGNAL Setting this causes the UDS II to ignore a termination signal from RS-HD and not enter emergency stop mode. Refer to section II below for this and other RS-HD as well as DCS-related environmental variables. 13 December 1999 ---------------- As of version 2.21k or greater (in the DPMI flavor of UDS II), there's support for a new environmental variable: UDS2_TIME_UPDATE_OLD_SKDS Setting this will allow time update commands to work on expired schedules, that is schedules whose dates do not match the current calendar date. Refer to Section VI below for more information on this and a variety of other environmental variables. 4 November 1999 --------------- As of version 2.20x of the UDS II (DPMI only), there's support for a new environmental variable: UDS2_ALT_GREY_PLUS. Setting this will enable the Alt-Grey-Plus key to perform a PrtScr-style segue. Refer to Section VI below for more information on this and a variety of other environmental variables. 22 July 1999 ------------ Note that all applicable DCS-related environmental variables have an equivalent name for On Air's "Radio Suite Hard Drive". Substitute "DCS" with "RSHD" in the text string. 14 May 1999 ----------- As of version 2.18gà of the UDS II, there's support for a new environmental variable: HD_CATASTROPHIC_FAIL. It performs a role similar to CDK3600_LOAD_FAIL in that it keeps track of failures involving either the DCS or RS-HD digital audio playback units. The intent is to avoid removing an excessive number of events in the schedule due to a consecutive sequence of "catastrophic" errors involving the hard drive system. Read more about this variable in section II, below. 5 May 1999 ---------- As of version 2.18cà, which is still currently an internal release version, the following DCS-specific boolean environmental variable is supported: DCS_AUX_MARK_TIME It addresses a situation involving runtime resolution from the DCS, allowing the AUX mark time to prevail for screen display upon playback. Refer to section II below for this and other DCS-related environmental variables. 18 March 1999 ------------- As of version 2.16yà, which is currently an internal release version, the following DCS-specific boolean environmental variable is supported: DCS_0_DURATION_FAIL It addresses a very specific condition involving "date challenge" with rotating carts. Refer to section II below for this and other DCS-related environmental variables. 4 December 1998 --------------- - As of version 2.14e, an internal release version, as of this writing, a new value may be used for UDS2_RBDS: ASCII - If using UDS2_RBDS=ASCII, an additional environmental variable can optionally be set, UDS2_RBDS_MIN_LENGTH. Refer to section III. below for additional details on these and other RBDS-related environmental variables. 26 October 1998 --------------- As of version 2.12z, if using an RBDS-capable version of the UDS II equipped with a Flash Comm RBDS device and a DCS unit for digital audio, the cart identifier assigned to UDS2_RBDS_TA_CART is now supported via the "hotkey" window. Refer to section III, below for more details on RBDS-related environmental variables. 22 September 1998 ----------------- As of UDS II version 2.12a, UDS2_DENON_VERBOSE is no longer a boolean (on or off) value. Instead, it sets a "verbosity" level to determine what will be written to a diagnostic file. Refer to section V below where details CD player-related environmental variables are fully explained. 18 September 1998 ----------------- - Revised the allowable range of UDS2_DENON_WAIT_BEFORE_LOAD from 0 to 500 ticks to 180 to 500 ticks. - As of UDS II version 2.11s, a new Denon-related environmental was introduced: UDS2_DENON_LOAD_FAIL_RESET. Refer to section V below where details of these and other CD player-related environmental variables are explained. 2 September 1998 ---------------- As of UDS II version 2.10x, the user may now optionally specify a Denon-related environmental variable, UDS2_DENON_NO_D1_STOP. This determines how the UDS II will handle a stop command. This ENV, specific to a protected mode UDS II equipped with Denon 1400 support, is explained fully in section V below where details of this and other CD player-related environmental variables are found. - NOTE: UDS2_DENON_NO_D1_STOP is available for diagnostic purposes only. This should NEVER be set by the user unless instructed by On Air USA. 28 August 1998 -------------- As of version 2.10u of the UDS II software, the user may govern the "wait time" between the occurrence of a segue to when a DCS "queue cart" command is issued. Details on the newly introduced environmental variable DCS_QUEUE_WAIT are found in section II below where this and other DCS-related environmental variables are explained. 14 August 1998 -------------- As of version 2.09v of the UDS II software, the environmental variable UDS2_DENON_NO_D1_RELOAD was added. This determine what action UDS II will take during an unexpected response during a Denon 1400 load process. This ENV, specific to a protected mode UDS II equipped with Denon 1400 support, is explained more fully in section V below where details of all CD player-related environmental variables are found. 13 August 1998 -------------- As of version 2.09t of the UDS II software, support for a new environmental variable was added: UDS2_UPDATE_90_FLIP will determine how the UDS II (operating in a UDS-HD context) will handle a situation wherein the target of a Time Update 90 is a DCS source conflicting with the source number of the airing backfill cart. See section II below for a details on this and other DCS-related environmental variables. 11 August 1998 -------------- Note that the purpose of environmental variables is to modify the behavior of the UDS II for special needs. The default actions of the UDS II will generally "do the right thing". In particular, there's no need for explicitly setting any DCS-related ENVs for using either: Time Update 90 UDS-HD This is not to imply that the user is prohibited from tuning the operation of the system via environmental variables -- only that, in the majority of the cases, there's no need to do so. 14 July 1998 ------------ A new environmental variable was introduced with the advent of UDS II version 2.08p (DPMI version only). Read more about UDS2_NO_VOICETRACK_REMOVAL in Section VI below. 10 July 1998 ------------ Two new environmental variables are present in the UDS II with a version of 2.08j (or greater). Both of these environmental variables deal with the new "Auto-Route" feature: UDS2_AUTO_ROUTE UDS2_AUTO_ROUTE_FADE Refer to the notes in Section VI below for the complete details on each of these new ENVs. 6 July 1998 ----------- - As of version 2.07x of the UDS II software (DPMI only with an equipment file specifying a UDS-HD configuration), the user may optionally set UDS2_DCS_PRIMARY_SOURCE to specify the source that will be used for hotkeys and other non-music items from the DCS unit. Refer to section II (below) for more details on this and other ENVs relating to the DCS. - As of version 2.07v of the UDS II software (DPMI or otherwise), the system behaves as though the value for UDS2_TRACK_CHANGE_TIME were set to 3. This decreases the possibility of a premature segue caused by the errant receipt of a track change indicator. Note that the user may now explicitly set this value to 0 to cause the UDS II to behave as it did prior to the change made in version 2.07v. 26 June 1998 ------------ As of version 2.07f of the UDS II (DPMI or otherwise), the user may optionally set the following boolean environmental variable: UDS2_NO_ALARM. This ENV, explained more fully in Section VI below, disables the audio mixer alarm for conditions other than silence sense. 25 June 1998 ------------ The relationship between DCS_STREAMS and DCS_NEW_VERSION merits disambiguation. The only DCS unit capable of three "playback resources" (or "streams", to use the Computer Concepts term) is one that is hosted on a 486 platform. The 286-based DCS units have only two such playback resources. Setting DCS_STREAMS=3 tells the UDS II that there are three playback "streams" available from the DCS. Because this number of streams is available only on a 486-based DCS, it _ALSO_ performs the side-effect of causing the UDS II to behave *as if* DCS_NEW_VERSION=1 was set. Of course, it doesn't actually go out to the environment and set this value...because it happens internally within the UDS II. It's a matter of applying some boolean logic: - All DCS units with three streams set are 486-based units. - Not all 486-based DCS units, though, need to have three streams set (from the standpoint of the UDS II). This begs the question of what exactly these two environmental variables do. Here's a brief summary (with more details found in the UDS2_ENV.TXT sections dealing with each ENV): 1). DCS_NEW_VERSION: In a nutshell, when a halt command is sent to the DCS, a response is expected back from the DCS confirming that the cart was, in fact, halted. However, the 286-based DCS units do NOT respond with such a "halt confirmation". As a result, the UDS II must make a presumption that the cart was halted. The 486-based DCS does confirm that a halt was successful. So, the UDS II behaves differently after a halt when the user asserts that a 486-based DCS is in use via DCS_NEW_VERSION. It doesn't have to perform some software "kludges" based on a lack of data coming back from the DCS. - Note that as of version 2.09k of the UDS II software, the _equivalent_ of setting DCS_NEW_VERSION=1 automatically occurs if the equipment file shows UDS-HD sources. This is because a UDS-HD requires a 486-based platform. 2). DCS_STREAMS: Briefly, the UDS II presumes that a maximum of two playback resources are available from a DCS unit. Prior to airing a cart, the UDS II does a check of an internal array to determine if a playback resource is available. By default, this array is based on the assumption that two carts airing at the same time means that the DCS is busy. If the user asserts that DCS_STREAMS=3, then the UDS II will only act as if the DCS is busy when it determines that there are three carts airing at the same time. - Note that as of version 2.09k of the UDS II software, the _equivalent_ of setting DCS_STREAMS=3 automatically occurs if the equipment file shows UDS-HD sources. This is because a UDS-HD requires that there be three playback resources available from the DCS unit. 9 June 1998 ----------- As of version 2.05u of the UDS II, with support for the Denon 1400 (this implies DPMI), the user may optionally "tune" the environmental variable: UDS2_DENON_D1_COUNT. This ENV is explained more fully in section V below where details of this and other CD player-related environmental variables are found. 4 June 1998 ----------- References throughout this document referring to "Denon 1400F" or "DN1400F" were modified to show "Denon 1400". 29 May 1998 ----------- As of version 2.04x of the UDS II -- all "flavors", DPMI or otherwise -- the user may optionally set UDS2_AUDIO_MIXERS to a value of between 1 and 7. This allows "virtual sources" to be used (without being under the control of an A4000 audio mixer). Refer to the notes in Section VI of this file to learn more about this feature and why it might be helpful. 22 May 1998 ----------- As of version 2.04t of the UDS II (DPMI version only), the user may optionally set UDS2_AUTO_UPDATE to cause a periodic automatic recalculation of "scheduled at" start times. Refer to the notes in Section VI of this file to learn more about this enhancement. 13 May 1998 ----------- As of version 2.04l of the UDS II (all versions), the user may now optionally set an environmental variable to determine at what point in time a "CD track change detection" is considered to be valid. This ENV (UDS2_TRACK_CHANGE_TIME) is explained more fully in section V below where details of this and other CD player-related environmental variables are found. 20 April 1998 ------------- a). As of version 2.02u of the UDS II (presuming a DPMI version, which is capable of handling Time Update 90), there is no longer a need to set the two DCS-related environmental variables (explained in the 9 April 1998 notes). When processing "Time Update 90", the segue code 008 emitted by the update itself (after a backfill substitution has been successfully performed) will lead to a fade and/or a halt. The notes of 9 April 1998 have been left in place for archival purposes only. Note that there are still reasons why either (or both) of the environmental variables (DCS_HALT_PRIOR and DCS_83_FADE) may still be set by the user. However, the setting (or lack thereof) of either (or both) no longer has any bearing on the behavior of "Time Update 90" (after a backfill substitution has been performed). b). The environmental variable DCS_HALT_PRIOR was modified as of UDS II version 2.02v. This change is not limited to the DPMI release, impacting all UDS II versions supporting a DCS unit. Please refer to the revised detailed explanation in Section VI later in this document. In a nutshell, the value of DCS_HALT_PRIOR can be thought in terms of a DIP switch model, with positions 0, 1 and 2 as follows: 0: Halt prior DCS cart on receipt of segue code 001 or 007. 1: Halt prior DCS cart on receipt of any segue code _other_ than 001, 007 or 008. 2: Halt prior DCS cart on receipt of segue code 008. In reality, there's not a DIP switch -- but a binary "bit vector" that gets set via the environmental variable. - For instance, if a user wants a halt command to be sent to a prior airing DCS event on segue codes 001, 007 or 008, bit 0 (with a value of 1) and bit 2 (with a value of 4) would be "turned on". The total value would then be 5. - Presuming the user wants to only halt a previously playing cart (DCS or RS-HD) when either time update 81 or 90 occurs, the setting of the value would be 4. This causes a halt to be sent upon receipt of segue code 008 (trigged by either update 81 or 90). If the airing event is an MOHD event, a smooth fade occurs prior to the halt, otherwise the cart is halted upon the start of the next event. - As another example, if a user wishes a halt command to be sent to the prior airing DCS cart on all segue codes except 001 and 007, bit 1 (with a value of 2) and bit 2 (with a value of 4) would be "turned on". The total value would then be 6. 16 April 1998 ------------- - As of UDS II version 2.02q, a DPMI instance of the software with the capability of the "enhanced voice track" feature now behaves as though UDS2_VOICETRACK_FADE were set to -0.1. This default behavior causes a rapid "fade up" of the music playing under a DCS voice track cart upon detection of the EOF from the DCS unit. If this default behavior is not desired, the environmental variable can be set to another value as described in Section VI below. 15 April 1998 ------------- - As of UDS II version 2.02p, a DPMI instance of the software, which has the "enhanced voice track" feature available now extends the functionality of the UDS2_VOICETRACK_FADE ENV. Unlike, the real mode versions of the UDS II, the DPMI version allows both negative and fractional (non-integral) values for this environmental variable. Refer to the notes in Section VI of this file to learn more about the enhanced functionality now afforded with UDS2_VOICETRACK_FADE. 9 April 1998 ------------ - As of UDS II version 2.02g, a DPMI instance of the software with a DCS unit as part of the equipment provides support for "Time Update 90". This permits a list of backfill carts to be allocated by the user. Upon encountering a time update with source 90, the UDS II is capable of substituting an event within a "backfill window" to a DCS cart of an appropriate length. In order for this function to work properly, here are two already existing environmental variables that must be set as follows: "DCS_HALT_PRIOR=3" -or- "DCS_HALT_PRIOR=13" "DCS_83_FADE=1" Note that although DCS_83_FADE contains the string "83", it also applies to time update source 90. (In most respects, time update 90 mimics the behavior of time update 83, with the notable exception of providing backfill capability). For more information on the operation of "Time Update 90", refer to UDS II printed documentation or the "README" file supplied with the distribution software. 31 March 1998 ------------- - As of UDS II version 2.01u, support for the UDS2_DENON_TC_STUCK environmental variable was added. Setting this to a legal value governs how the UDS II will respond to "repeated" time code from a Denon 1400 CD player. This ENV is explained more fully in section V below where details of this and other CD player-related environmental variables are found. 20 March 1998 ------------- - As of UDS II version 2.01i, support for the UDS2_DENON_WAIT_BEFORE_LOAD environmental variable was introduced. Setting this to a valid value determines the wait time between the receipt of a stop acknowledgment from a Denon 1400 CD player and the initiation of a load sequence. This ENV is explained more fully in section V below where details of this and other CD player-related environmental variables are found. 2 March 1998 ------------ - As of UDS II version 1.99k, UDS2_NO_MUSIC_CLOSURE was introduced as a new environmental variable. Setting this causes the UDS II to ignore "contact closures" (external print screen) when non-contact closures events are airing. This ENV is explained more fully in section VI below where *all other* environmental variables are explained in detail. 25 February 1998 ---------------- - As of UDS II version 1.99g, UDS2_DENON_VERBOSE was introduced as a new environmental variable. Setting this causes the UDS II to write diagnostic logging information to the DENON.DRB file in the current working directory. See section V below for details on this and other CD player-related environmental variables. 2 February 1998 --------------- - As of UDS II version 1.96w, UDS2_TRACK_ZERO was introduced as a new environmental variable. Setting this allows the UDS II to accept a music database entry with a track of 0. This ENV (and the reason for its introduction) is explained more fully in section VI below where *all other* environmental variables are explained in detail. 15 January 1998 --------------- - As of UDS II version 1.95h, UDS2_STUDIO_OFF_AT_SEGUE was introduced as a new environmental variable. Setting this causes the UDS II to fade the live studio source when a segue occurs. This ENV is explained more fully in section VI below where *all other* environmental variables are explained in detail. - As of UDS II version 1.95g, a new environmental variable was added so that the user can set a threshold value to allow the line printer to begin printing. This ENV is explained more fully in section VI below where *all other* environmental variables are explained in detail. This new variable is UDS2_PRINTER_DELAY. 13 January 1998 --------------- As of UDS II version 1.95a, a new environmental variable, UDS2_LOAD_PROTECT, has been introduced to "fine tune" the error handling of UDS II when a CD player is unable to load a disc. Refer to Section V for the details included in the summary of all ENVs relating to CD players. 9 January 1998 -------------- As of UDS II version 1.94s, a new environmental variable has been introduced to work in conjunction with UDS2_UPDATE_81. This new variable is UDS2_UPDATE_MUSIC. Read the detailed explanation in Section VI (following the explanation of UDS2_UPDATE_81). 2 December 1997 --------------- As of UDS II version 1.92sà, a new environmental variable has been added: UDS2_NO_RELOAD_WARN. This suppresses the normal F4 editor warning message: "Insufficient time to reload, proceed anyway?" This ENV is explained more fully in section VI below where *all other* environmental variables are explained in detail. 26 November 1997 ---------------- As of UDS II version 1.92oà, a new environmental variable has been added: UDS2_NAK_TIMEOUT. This determines how the UDS II will handle a condition involving a series of NAK responses while a Sony CDK-006, NSM3101AC or Denon 1400 CD player is airing a compact disc event. See section V below for details on this and other CD player-related environmental variables. 14 November 1997 ---------------- Added information about the Ctrl-F9 key to select a playback channel on the DCS unit. 12 November 1997 ---------------- As of UDS II version 1.91n, a new environmental variable has been added: UDS2_NO_IMPORT_WARN. This determines how the UDS II will react at import time if a schedule is to be loaded with an ending event prior to the 11:00 PM (or 23:00) hour. Refer to the more detailed notes in section VI below where *all other* environmental variables are explained. 2 October 1997 -------------- As of UDS II version 1.89t, a new environmental variable has been added: DCS_PLAYOUTDATE. This determines how the UDS II will handle a cart reported as "outdated" by the DCS. See section II below for details on this and other DCS-related environmental variables. 24 September 1997 ----------------- As of UDS II version 1.89e, a new environmental variable has been added: DCS_83_FADE. This determines how the UDS II will handle DCS audio in the event of a time update 83 occurring when a DCS channel is airing. See section II below for details on this and other DCS-related environmental variables. 18 September 1997 ----------------- As of UDS II version 1.88z, a new environmental variable has been added: DCS_SS_FADE. This determines how the UDS II will handle DCS audio in the event of a silence sense. See section II below for more details on this and other DCS-related environmental variables. 16 September 1997 ----------------- Two new environmental variables were introduced with UDS II v1.88w: UDS2_RS422_XMIT_TIME UDS2_RS422_RCV_TIME Both of these permit the user to "tweak" timeout values associated with RS422 communications. Refer to section IV (hardware-related ENVs) for more details on these items. 4 September 1997 ---------------- If DCS_CHANNEL is set to -1, the F6 information display for the "Channel" field now properly shows "-1". See the notes below for additional details. 28 August 1997 -------------- The DCS platform and version are logged to the DIALOG file as part of the DCS operating parameters as of UDS II version 1.87w. - If DCS_STREAMS is set to 3 or DCS_NEW_VERSION is defined, then the following message is logged: "DCS platform: 486/version 2.5 or later" - Otherwise, the following message is logged: "DCS platform: 286/version 2.35 or earlier" 27 August 1997 -------------- The newly introduced ENV, DCS_NEW_VERSION was added to the list of environmental variables supported by the UDS II as of version 1.87u. 26 August 1997 -------------- The newly introduced ENV, DCS_NO_HALT_HOTKEY was added to the list of environmental variables supported by the UDS II as of version 1.87t. 25 August 1997 -------------- The newly introduced ENV, DCS_STREAMS was added to the list of environmental variables supported by the UDS II as of version 1.87s. 22 August 1997 -------------- The ENV, DCS_HALT_PRIOR was expanded to accept values of 11, 12 and 13 as well as 1, 2 and 3. 21 August 1997 -------------- The newly introduced ENV, DCS_STOP_EXIT was added to the list of environmental variables supported by the UDS II as of version 1.87p. 19 August 1997 -------------- The newly introduced ENV, DCS_HALT_PRIOR was added to the list of environmental variables supported by the UDS II as of version 1.87l. 21 July 1997 ------------ The newly introduced ENV, DCS_CHANNEL was added to the list of environmental variables supported by the UDS II as of version 1.86d. 14 May 1997 ----------- The newly introduced ENV, UDS2_UPDATE_81 was added to the list of environmental variables supported by the UDS II as of version 1.85h. 12 May 1997 ----------- The newly introduced ENV, UDS2_DBASE_VERBOSE was added to the list of environmental variables supported by the UDS II as of production release DPMI version 1.85g. 9 May 1997 ---------- The newly introduced ENV, UDS2_NO_FAIL_SAFE was added to the list of environmental variables supported by the UDS II as of production release version 1.85e. 16 April 1997 ------------- The newly introduced ENV, UDS2_NO_F3_SEGUE_REFRESH was added to the list of environmental variables supported by the UDS II as of version 1.84sá. 26 March 1997 ------------- The new ENV, CDK3600_VERBOSE was added to the list of environmental variables supported by the UDS II as of version 1.83zá. 21 March 1997 ------------- This file was reorganized today. There's now an entire section dedicated to environmental variables associated with the Sony CDK-3600 player. Note also that the maximum allowable value for CDK3600_TRACK_RETRY is now 25 (it was 15). 20 March 1997 ------------- The new ENV, CDK3600_TRACK_RETRY was added to the list of environmental variables supported by the UDS II as of version 1.83pá. 12 March 1997 ------------- The new ENV, CDK3600_TC_RETRY was added to the list of environmental variables supported by the UDS II as of version 1.82wá. 28 February 1997 ---------------- - Spell checking and reformatting completed as well as a thorough review for informational accuracy. - The name of the file was changed from UDS2_ENV.!!! to UDS2_ENV.TXT. 5 February 1997 --------------- The newly introduced ENV, UDS2_PREVIEW_RESPONSE was added to this list of environmental variables supported by the UDS II as of version 1.80zá. Note that this ENV is entirely different from both DCS_EXIT_PREVIEW and DCS_HALT_PREVIEW. Unlike the former, it does not depend upon the setting of any other ENV to take effect. 29 January 1997 --------------- The new ENV, DCS_EXIT_PREVIEW was added to the list of environmental variables supported by the UDS II as of version 1.80vá. Note that this ENV is different from DCS_HALT_PREVIEW but is dependent upon the latter ENV being set. 26 November 1996 ---------------- The new ENV, DCS_HALT_PREVIEW was added to the list of environmental variables supported by the UDS II as of version 1.78bà. 1 November 1996 --------------- The new ENV, UDS2_VOICETRACK_FADE was added to the list of environmental variables supported by the UDS II as of version 1.76ià. 11 July 1996 ------------ The new ENV, UDS2_ROOT was added to the list of environmental variables supported by the UDS II as of version 1.72fà. 26 June 1996 ------------ The new ENV, CDK3600_LOAD_FAIL, was added to the list of environmental variables supported by the UDS II as of version 1.71là. 20 May 1996 ----------- NOTE: In this text, "ENV" is commonly used as an abbreviation for the full expression of "environmental variable". The charts below are organized so that ENV Name is the variable to set in the user's environment. The environment is set using the command SET = where is one of the strings shown in the charts below, is one of the numbers or strings shown in the charts below. An explanation of the role of each is included in the chart, prepended with a '-' and indented one tab stop in the first line following the . - Both ENV_NAME and VALUE are case insensitive for the purposes employed by the UDS II. By convention, upper-case is generally used in the MS-DOS environment for setting of ENVs. - There must be NO space in the string. - There must be NO space on either side of the '=' assignment operator. - A BOOLEAN type simply indicates whether the ENV is set or not. By convention, a VALUE of 1 is typically used to set a BOOLEAN. Note that setting a BOOLEAN ENV to a value of "0" does NOT unset the ENV...it simply sets it to the value of "0". Under a stock version of MS-DOS' COMMAND.COM, the *only* portable way to unset an ENV is to use the following: SET = Setting an to the empty string (without any trailing whitespace after the '=' assignment operator) will remove the from the environment. ==================================================================== I. Here is a summary of ALL current AV100-related ENV user-configurable parameters: ------------------------------------------------------------ ENV NAME VALUE Default Units ------------------------------------------------------------ AV_RS422_TIMER 7-60 37 Ticks - Number of ticks elapsed, while awaiting a character, before RS422 routines error out. AV_LOAD 0.5-12.0 1.5 Seconds - Amount of time that elapses between the start of a cart and the load command issued for the next. AV_LOAD_VERIFY 0.5-12.0 1.5 Seconds - Amount of time that elapses between the load request and the first polling attempt to determine if the load was successful. AV_LOAD_FAIL 1-35 10 Iterations - Number of attempts that the UDS II will continue to poll the AV100 (when a load error is returned) until finally deciding that the cart can't be loaded and then fail it. AV_PLAY_FAIL 1-35 10 Iterations - A counter is incremented each 1/10 of a second if a failure is noted while checking the running status of the cart. If this counter is exceeded, the cart fails with segue code 10 (Digital Audio playback failure). AV_QUERY 1-10 3 Iterations - Number of iterations the UDS2 must attempt an AV100 "general hardware query" before presuming that AV100 is, in fact, dead. AV_PLAYOUTDATE BOOLEAN UNSET - Forces UDS2 to accept an outdated cart as suitable for loading. AV_FORCE_PINGPONG BOOLEAN UNSET - A deprecated ENV, support for which, may be withdrawn in future versions. At present, it forces each instance of an AV100 deck search routine to alternate from the deck most recently loaded. (Much of its functionality is now built into the code). AV_CLEAR_DECK BOOLEAN UNSET - Upon receipt of an EOF from a deck where a load is attempted while a cart is still playing, an explicit stop command is sent by the UDS II to the AV100. This allows the deck to be loaded without failure when running, for instance, a long traffic bed into a spotset -- requiring that the deck playing the long traffic bed be loaded while the first spot is playing. AV_CONFIRM_EOF BOOLEAN UNSET - Forces the UDS2 to first checks to ensure than an EOF was received on a deck before attempting to issue a load request to that deck. (This ENV does not behave well with firmware version 1.05). AV_LOAD_E6 BOOLEAN UNSET - After a load command is transmitted to the AV100 and if an E6 is returned by the AV100, a reload of that cart occurs rather than a continued re-polling of the AV100. It is presumed that an E6 error is errant in this context -- since it is not one of the errors associated with a load failure. This approach has the blessing of Broadcast Electronics. AV_WAIT_AX BOOLEAN UNSET - Polling continues on the AV100 deck even after EOF is received until an "A" (deck available) response is received. (This ENV does not behave well with firmware version 1.05). AV100_DEBUG BOOLEAN UNSET - Forces an EXTREMELY verbose diagnostic dribble file (AV_BUG.DRB) to be written to the CWD. WARNING: this dribble file can easily consume a typical Z-4000 computer's hard drive space in a matter of 2 days of dribbling. It should only be enabled per the instructions of On Air USA and the file should be unlinked as soon as possible. > NOTE: As of v1.80cà, the creation of dribble files is supported *only* with the protected (DPMI) version of the software. In all other versions, this environmental variable does nothing. ==================================================================== II. Here is a summary of ALL current digital audio-related ENV user-configurable parameters: ------------------------------------------------------------ ENV NAME VALUE Default Units ------------------------------------------------------------ DCS_DEBUG BOOLEAN UNSET - Enables a diagnostic dribble file (DCS_BUG.DRB) to be written to the CWD, showing the state of all DCS-related variables when each message is transmitted and received from the DCS via the RS-232 port. This produces a reasonably large file but it is not nearly as huge as the AV_BUG.DRB diagnostic dribble file. > NOTE: As of v1.80cà, the creation of dribble files is supported *only* with the protected (DPMI) version of the software. In all other versions, this environmental variable does nothing. If this variable is set and the DPMI version is in use, the following message gets logged upon program invocation in the DIALOG file: "DCS diagnostic file: ON" If unset and the DPMI version is in use, the message shows: "DCS diagnostic file: OFF" DCS_NO_HALT_CART BOOLEAN UNSET - Not to be confused with DCS_NO_HALT_EXTERN. The normal behavior is to permit the PrtScr key to be pressed even while all DCS channels are busy. By default, the least recently accessed DCS element is then halted -- and the current DCS element begins playing immediately. If DCS_NO_HALT_CART is set, then the least recently accessed DCS element continues to play and results in a "channel busy" situation. If properly set in the environment, the following message appears in the DIALOG file along with other DCS parameters: "UDS originated carts will be halted to avoid channel busy" DCS_NO_HALT_EXTERN BOOLEAN UNSET - The normal mode of operation (presuming a DCS with two playback channels) is to halt a non-UDS originated cart when the UDS II is playing a DCS element. This default behavior is designed to avoid a "channel busy" situation. If this ENV is set, the UDS II does not attempt to halt an externally playing cart, such as a cart being auditioned in a production environment. If set in the environment, this message gets written to the DIALOG file upon program invocation: "Non-UDS originated carts will NOT be halted on playback" DCS_HALT_PREVIEW 1-30 0 Seconds - Because there is some latency involved between halting a cart played from the hotkey window in preview mode and starting one for airing, the user may optionally set this value to halt such a previewed cart at a defined time *prior* to segue to a DCS event. If this ENV is set, the DIALOG file shows this value via the following message: "DCS previewed carts halted within seconds of segue" where is the setting of DCS_HALT_PREVIEW. At runtime -- if this value is set -- and a DCS cart is being previewed, when the currently airing event's backtime counter is less than the user-defined value (and a DCS event is next), the previewed element is halted and the following message appears on the UDS II's main screen and is written to the DIALOG file: "Halting preview cart: " DCS_EXIT_PREVIEW BOOLEAN UNSET - This variable _only_ becomes active if DCS_HALT_PREVIEW is set to a valid value, (see above). If DCS_EXIT_PREVIEW is set in the environment and the user is previewing a DCS cart and the threshold (as set by DCS_HALT_PREVIEW) of a pending scheduled DCS event is reached, the hotkey window is automatically closed. This is designed to avoid accidentally playing a hotkey on the air. (If preview mode is halted, per DCS_HALT_PREVIEW, the hotkey window reverts to non-preview mode. All subsequent keypresses then lead to a cart airing as a hotkey). If this variable is set, the following message gets logged upon program invocation in the DIALOG file (under the message for DCS_HALT_PREVIEW): "* DCS hotkey window closed if preview active at this time" NOTE: The phrase "at this time" refers to the threshold of "within seconds of segue" as described in the DCS_HALT_PREVIEW section. DCS_CHANNEL -1 to 1 0 Channel Number This may be set to any of the following three values: -1, 0 or 1. Setting DCS_CHANNEL to either 0 or 1 establishes the playback channel selected for all UDS-originated events on the DCS unit. Note that the default remains channel 0, which appears as the top channel line on the DCS unit. (If this environmental variable is unset, the default of channel 0 will be selected for playback). The DCS playback channel is now also logged to both the DIALOG and UDS2BOOT.LOG as part of the "Computer Concepts DCS parameters" stanza, either: "Audio channel: 0" or "Audio channel: 1". If set to -1, the designated playback channel is considered to be "undefined". This means that the channel selected for active playback on the DCS unit will be used. (This may be useful for clients wishing to manually alternate between playback channels on the DCS unit). In the absence of a mouse or trackball connected to the DCS unit, one may select the output channel by pressing Ctrl-F9. Note that this keystroke is NOT supported in satellite mode -- but is available in source mode. This does lead to a bit of a problem, though, because only satellite mode provides a display indication of the current mode (via the smiley face in the upper left-corner of the DCS screen). If DCS_CHANNEL is set to -1, the following is logged to both the DIALOG and UDS2BOOT.LOG as part of the "Computer Concepts DCS parameters" stanza: "Audio channel: UNDEFINED". IMPORTANT: The equipment window (accessed via F6 or Alt-E) will show "-1" if the ENV DCS_CHANNEL is set to -1. This is normal. Since the setting of DCS_CHANNEL=-1 via the environmental variable takes precedence over the F6 setting, that "Channel" field may no longer be modified by the F6 equipment window. If an explicit channel setting is desired via F6, the DCS_CHANNEL environmental variable must be unset. DCS_HALT_PRIOR 1 through 9 UNSET 11 through 17 This optional environmental variable may be used to cause the UDS II to halt the play of a previously airing DCS cart when the "next to air" DCS event moves to "on the air" and begins to play. The normal behavior of the UDS II relative to DCS events is to allow each DCS event to play fully to conclusion "over" the next DCS event...thus permitting DCS events to overlap. This environmental variable may be "tuned" (by using a value of 1 through 7 or 11 through 17, inclusive) in accord with the specific needs of the user as follows: 1: Halts the prior DCS event *only* if the "next to air" DCS cart is started by explicit operator intervention, eg., press of the PrtScr key or press of an external push button. These correspond to segue codes 001 and 007. 2: Halts the prior DCS event *only* if the "next to air" DCS cart is started by something *other* than explicit operator intervention. Typically, a DCS to DCS segue occurs upon receipt of the "EOM/AUX" mark, which is segue code 012. Segue code 008 (from either time update 83 or 90) is excluded. 3: Halts the prior DCS event regardless of the type of segue that occurs so long as it is a segue code other than 008, which is emitted by either time update 83 or 90. 4: Halts the prior DCS event *only* if the "next to air" DCS cart is started by a time update 83 or 90 yielding a segue code of 008. 5: Halts the prior DCS event if the "next to air" DCS cart is started by explicit operator intervention, eg., press of the PrtScr key or press of an external push button. These correspond to segue codes 001 and 007. It also halts the prior DCS event if the "next to air" DCS cart is started by a time update 83 or 90 yielding a segue code of 008. 6: Halts the prior DCS event if the "next to air" DCS cart is started by something *other* than explicit operator intervention. Typically, a DCS to DCS segue occurs upon receipt of the "EOM/AUX" mark, which is segue code 012. It also halts the prior DCS event if the "next to air" DCS cart is started by a time update 83 or 90 yielding a segue code of 008. 7: Halts the prior DCS event if the "next to air" DCS cart for any and all segue codes. 8: RESERVED 9: Halts the prior DCS (or RS-HD) event regardless of what the next to air event is. This is an extention of setting 7 (as described above) in that, for any and all segue codes, the currently airing non-music cart is halted -- regardless of the type of "next to air" source. - Note that although the prior DCS cart isn't halted until the "next to air" cart has begun airing, there is still the potential for a "choppy" segue since there is no fading of the prior halted event. When a DCS event is halted, it simply stops the cart. - If set to a value of 11, 12, 13, 14, 15 or 16, the "halt" behavior is more aggressive: 11 corresponds to 1 (as explained above) 12 corresponds to 2 (as explained above) 13 corresponds to 3 (as explained above) 14 corresponds to 4 (as explained above) 15 corresponds to 5 (as explained above) 16 corresponds to 6 (as explained above) 17 corresponds to 7 (as explained above) The difference in all of these cases (11 through 17) is that the UDS II *FIRST* halts the prior scheduled cart if a "DCS channels busy" condition is detected *BEFORE* it plays the "next" DCS cart. - The setting of this optional environmental variable is logged to the DIALOG file as follows: "DCS_HALT_PRIOR set: " where is either 1 through 7 or 11 through 17. DCS_STOP_EXIT 1, 2 or 3 UNSET This optional environmental variable may be used to cause the UDS II to stop a playing DCS event when exiting the program or when changing to STOP mode. Normally the UDS II does not explicitly stop a DCS cart under either circumstance. This environmental variable may be "tuned" (by using a value of either 1, 2 or 3) in accord with the specific needs of the user as follows: 1: Stops a playing DCS cart *only* when successfully exiting the UDS II via the "Alt-X" keystroke. 2: Stops a playing DCS cart *only* if the mode was successfully changed to STOP via the "Alt-F2" keystroke. 3: Stops a playing DCS cart regardless of whether the program was exited via Alt-X or the mode was changed via Alt-F2. - The setting of this optional environmental variable is logged to the DIALOG file as follows: "DCS_STOP_EXIT set: " where is either 1, 2 or 3. DCS_STREAMS 2 or 3 2 This optional environmental variable may be used to set the number of available "DCS playback streams". DCS "control room" software (CMCR.EXE) versions in the 2.5 series running on the 486 platform use a dynamic "3 plus zero" method, which means that up to three playback "streams" are available (if one "stream" is not already occupied with recording). Setting this value to 3 enables the UDS II to permit the playback of up to three simultaneous DCS items at once, presuming that the a record line is not in use or that the DCS isn't already using a playback resource, such as playback of a cart through the audition channel. This value should NOT be set unless necessary and it should absolutely NOT be set for a DCS running on a 286 platform with a version of DCS software prior to 2.5. NOTE 1: Setting this value to 3 will automatically cause the equivalent of DCS_NEW_VERSION to be set. It doesn't mean that DCS_NEW_VERSION is mysteriously set in the environment. Instead, it means that the UDS II behaves *as if* DCS_NEW_VERSION were set. (See the notes below for more details regarding DCS_NEW_VERSION). NOTE 2: If DCS_NEW_VERSION is set, DCS_STREAMS still defaults to 2. Merely setting DCS_NEW_VERSION does not coerce the use of three streams. In fact, for users with a DCS 486-based platform, DCS_NEW_VERSION=1 is probably the preferred configuration. It essentially forces the UDS II to behave in the most conservative manner possible with regard to the DCS. DCS_NO_HALT_HOTKEY BOOLEAN UNSET - Not to be confused with DCS_NO_HALT_EXTERN or DCS_NO_HALT_CART, the normal behavior of the UDS II is to allow scheduled carts to always take precedence over hotkey carts. This means that if the UDS II determines the DCS is in an "all channel busy" situation when a cart is to be aired by schedule, it will halt a hotkey cart to free up a channel. Because it is so vital to permit scheduled carts to air, it is strongly recommended that this variable remain unset. DCS_NEW_VERSION BOOLEAN UNSET - If the user's DCS platform is a 486 or better and the DCS control room (CMCR.EXE) software is version 2.35 or greater, this ENV should be set. There is a significant difference in the behavior of DCS systems running on a 286 and those on a 486 or greater. In particular, a "halt cart" command does not result in an EOM/EOF message back from the DCS. As a result, the UDS II must perform a workaround to behave as if this EOM were received. Similarly, there are cases when the DCS properly responds with an EOM (AUX mark) response...but does not follow up with an expected EOF response. Again, the UDS II attempts to workaround this by fabricating a an EOF response. Because the DCS software designed for the 486 is much more reliable in these responses, it is STRONGLY recommended that the user set this variable to bypass the workarounds now in place to deal with the DCS software for the 286 platform. NOTE 1: Setting DCS_STREAMS to 3 will automatically cause the *equivalent* of DCS_NEW_VERSION to be set. It does not actually set that environmental variable -- but causes the UDS II to act as though it were set. (See the notes above for more details regarding DCS_STREAMS.) NOTE 2: If DCS_NEW_VERSION is set, DCS_STREAMS still defaults to 2. Merely setting DCS_NEW_VERSION does not coerce the use of three streams. In fact, for users with a DCS 486-based platform, DCS_NEW_VERSION=1 is the preferred configuration. It essentially forces the UDS II to behave in the most conservative manner possible with regard to the DCS. DCS_SS_FADE BOOLEAN UNSET - If set in the environment to a value of 1, the UDS II will fade and then turn off the DCS channel on the audio controller in the event of a silence sense leading to a segue of a non-DCS event. The normal behavior of the UDS II is not to fade the DCS channel until an EOM is received from the DCS, even in a silence-sense situation. If this variable is set, the following message is logged to the DIALOG file: "Channel will fade on silence sense" ...otherwise, the default message is: "Channel will not fade on silence sense" NOTE: The "DCS Fade Time" *MUST* be set to a non-zero value for this "fade out" behavior to occur! This may be set in the F6 equipment window corresponding to the DCS source number. DCS_83_FADE BOOLEAN UNSET - If set in the environment to a value of 1, the UDS II will fade and then turn off the DCS channel on the audio controller in the event of a time update 83 occurring which then leads into a segue of a non-DCS event. The normal behavior of the UDS II is not to fade the DCS channel until an EOM is received from the DCS, even in a silence-sense situation. If this variable is set, the following message is logged to the DIALOG file: "Channel will fade on time update 83" ...otherwise, the default message is: "Channel will not fade on time update 83" NOTE: The "DCS Fade Time" *MUST* be set to a non-zero value for this "fade out" behavior to occur! This may be set in the F6 equipment window corresponding to the DCS source number. DCS_PLAYOUTDATE BOOLEAN UNSET - Forces UDS2 to accept an outdated cart as suitable for loading and airing. In spite of turning off "date challenge", the DCS still reports to the UDS2 that carts are outdated, this ENV will force the cart to be queued and then be eligible for airing. If an "outdated" cart is encountered, the UDS2 displays this message on the screen and in the DIALOG file upon queuing the cart: "Cart outdated, will play anyway" Note that when such a reported "outdated" cart is queued, the runtime returned to the UDS2 by the DCS *may* be zero seconds. Thus, the display will show "0:00" for the duration of the cart. However, once the cart begins to play, the UDS2 again probes the DCS for the actual runtime. At the instance the cart starting play, the runtime is then readjusted to the proper value and displayed as such. If this value is set in the environment, the DIALOG file shows: "Outdated carts will play" The default message (without DCS_PLAYOUTDATE set) is: "Outdated carts will not play" UDS2_DCS_PRIMARY_SOURCE 1-30 Highest DCS channel By default, the "Primary Digital Audio Source" in a UDS-HD environment will default to the "highest" of the UDS-HD sources. Given the typical example of "07", "08" and "09", source 9 will be the one chosen for non-music elements, most notably hotkeys. However, should the user have a need to specify a source other than the "highest" as the "Primary Digital Audio Source", the environmental variable UDS2_DCS_PRIMARY_SOURCE may be set to a value ranging from 1 through 30, inclusive. In all cases with a UDS II equipped as a UDS-HD system, the following message is written to DIALOG and UDS2BOOT.LOG: "UDS-HD primary (and hotkey) DCS source: " UDS2_UPDATE_90_FLIP BOOLEAN UNSET - The user may optionally set this environmental variable to cause the UDS II (in a UDS-HD context only) to "flip" the DCS playback channel to a non-conflicting source number when Time Update 90 advances to the target of the update -- and that target item is a DCS source. Consider the following sequence: Src Event Status --- ----- ------ 09 BACKFILL CART On the air 90 TIME UPDATE @59:59 09 LEGAL ID Next to air As of UDS II version 2.09t, the "LEGAL ID" cart will play from channel 9 (which is defined, in this example, as the "Primary Digital Audio Source" from which non-music items (spots, hotkeys and backfill carts) will air. The result, when the segue occurs, is that "LEGAL ID" will start airing at 59:59 past the hour. Shortly thereafter (about 0.5 seconds), a halt command will be sent to the DCS to stop "BACKFILL CART". In most cases, this will be acceptable on the air since the "LEGAL ID" will "squash" the "BACKFILL CART" due to audio processing. However, there may be a desire to have the backfill cart do a fade in the event of a DCS to DCS transition. To make this happen, set the environmental variable UDS2_UPDATE_90_FLIP to 1. If thusly set, the DIALOG (and UDS2BOOT.LOG) will show the following in the startup stanza: "Time update 90 will flip conflicting DCS channels" At runtime, the above sequence of events will look like this: Src Event Status --- ----- ------ 09 BACKFILL CART On the air 90 TIME UPDATE @59:59 07 LEGAL ID Next to air Note that "LEGAL ID" was "flipped" to channel 07. Normally designated as a UDS-HD music channel, this is one occasion wherein a non-music element will play through that channel. The result on the air will be that "LEGAL ID" will air at 59:59 past the hour...and that "BACKFILL CART" will smoothly fade out (and thereafter be halted). The fade rate will be 1.5 seconds if the DCS channel's "Fade Time" is 0.0 (as set in the F6 equipment information window), or whatever the value of the user-defined "DCS Fade Time", up to a maximum of 3.5 seconds. DCS_QUEUE_WAIT 0.5-10 Seconds The user may now optionally set this environmental variable to govern an aspect of the UDS II's operation with the DCS. Setting DCS_QUEUE_WAIT to a floating-point value ranging from 0.5 to 10.0 determines how long the UDS II will wait (in seconds) to transmit a "queue cart" command to the DCS after a segue. The default value is 0.5 seconds. A "queue cart" command is performed by the UDS II to resolve the DCS item's title and duration and to pre-validate the cart's validity prior to play. - Note that a "queue cart" is not absolutely necessary to play a DCS cart. For instance, hotkeys are aired without first issuing such a queue. There are also situations where an extremely short DCS-to-DCS transition segue precludes such a queue. If a queue can't be done, the UDS II still attempts to play the cart anyway. There's a mechanism in place to handle the play of a non-existent cart. See the UDS II notes for version 2.08q for additional information. Each time a segue occurs, the UDS II evaluates the event in the "Next to air" position. If that event is a DCS item that hasn't already been "queued", the "queue cart" command is sent exactly 0.5 seconds after the segue (responsible for moving the DCS event into the "Next to Air" position) has occurred. However, there may be situations where such a rapid attempt to "queue a cart" after a segue isn't warranted. In that case, the user may govern the wait time by setting DCS_QUEUE_WAIT to values within the range enumerated above. NOTE: This user-defined wait time is applicable ONLY if a DCS event or Live Studio (on source 10) is not currently airing. The theory is that, for instance, a defined 3.5-second DCS_QUEUE_WAIT value is too long to allow a quick DCS-sourced legal ID (under 3.5 seconds) to permit a queue of the following DCS event to get queued. Also, there may be instances where the user pops in a quick live studio event between two DCS events and quickly advances through the live studio. In these cases, the default of 0.5 seconds is used. For all events other than a DCS or Live Studio, the value set via DCS_QUEUE_WAIT prevails. The "Computer Concepts DCS parameters" stanza of both DIALOG and UDS2BOOT.LOG show the current value of DCS_QUEUE_WAIT (regardless of whether the user explicit set it or not) as follows: "DCS Queue wait time: " where is a floating-point value between 0.5 and 10.0, inclusive. DCS_0_DURATION_FAIL BOOLEAN UNSET The user may now optionally set this environmental variable to govern an aspect of the UDS II's operation with the DCS in terms of handling a very narrow set of conditions involving date challenge with rotating carts. This has only been tested with with DCS version 2.6e. It's behavior with 286-based DCS units or other version is not currently known. Consider the following scenario, with the presumption that the current date is 18 March 1999. CART Date Range (Start/End) ------- --------------------------- 1202-01 1 March 1999-15 March 1999 1202-02 20 March 1999-31 March 1999 When the UDS II queries the DCS to determine if the cart is valid (during the QUEUE cart process), the DCS reports back "SQ001L00:00". The "001L" means that the cart exists and has no "date challenge" problem, in spite of the fact that there is no currently valid cart in the rotation. - The only hint that the UDS II has that something is amiss is the duration being reported as "00:00". Everything else is reported as OK by the DCS. In order to address the problem, if the user sets DCS_0_DURATION_FAIL to a value of 1, the cart will be rejected during the "queue cart" process with the following error message logged to the screen and to DIALOG: "Cart can't play, possibly outdated" * By the way, note that also setting DCS_PLAYOUTDATE to 1 results in the following message: "Cart possibly outdated, will play anyway" * This environmental variable is a UDS II workaround to addresses a flaw in the DCS (at least evident in version 2.6e). If both carts (in a rotating series) are expired, the DCS correctly reports back an "E01" so that the UDS II knows that the cart is outdated. Likewise, if both carts have only future dates, the DCS also reports an "E01" as part of the queue cart process. * Caution is advised in setting this environmental variable. Any cart will be rejected for play if the duration is reported as "00:00". This could encompass very short "shotgun jingles" or voice tracks. If this environmental variable is set, the following message is logged to both DIALOG and UDS2BOOT.LOG as part of the hard drive stanza: "0-second carts will be presumed outdated" Contrast this with the default message: "0-second carts will not be presumed outdated" DCS_AUX_MARK_TIME BOOLEAN UNSET As of version 2.18cà, the user may set this environmental variable to cause the AUX mark time to prevail when the UDS II attempts to resolve a cart's runtime. When the UDS II requests the duration of a cart from the DCS, during the QUEUE CART process, the DCS returns a runtime based on the AUX mark value. When that cart actually airs, the UDS II again gets a duration from the DCS as part of the response to the PLAY CART command. However, this value is the "absolute" runtime of the cart (to the end of the file) which may differ substantially from the AUX mark value. Normally, the UDS II resets the cart's duration based on this latter value. Setting this environmental variable to 1 causes the UDS II to allow the AUX mark duration to prevail, ignoring the "absolute" duration returned by the DCS when the cart begins to play. Note that if a cart does not go through the normal QUEUE CART procedure, perhaps due to an ultra-fast edit, the duration returned by the PLAY CART response is used regardless of the setting of this environmental variable. If this environmental variable is set, the following message is written to the DCS stanza of the DIALOG file: "Cart duration at playback based on AUX mark time" If unset, the default message is: "Cart duration at playback based on absolute time" HD_CATASTROPHIC_FAIL 1-100 (NONE) Failure count - If using a DPMI version of the software, the user may now set this environmental variable to a value between 1 and 100, inclusive. If there are that many instances of *consecutive* load or playback failures from the hard drive device, either the DCS or RS-HD, the UDS II goes into emergency stop mode. This avoids the unfortunate situation of all of the events in a schedule (or schedules) being deleted in the wake of this type of failure. If a successful load and playback occurs, the internal counter is reset to 0. It is important to note that this catastrophic handler only functions when in AutoSegue mode. If the system is in Live Control, the presumption is that an operator is present to deal with the situation. Consequently, heroic measures on the part of the UDS II are not called for. This handler is available only on DPMI versions. The reason is because there's a lot of code involved. Likewise, the situations where an entire schedule consists only of hard-drive based items is not likely to occur in a non-DPMI setting. Also, there's no support for this handler with the AudioVault. The user is alerted to such a condition by noting that the system automatically went into STOP mode and is accompanied by an on-screen flashing yellow on red message: "EMERGENCY: * Hard drive fail count exceeded, stopping UDS2 *" Once the problem with the hard drive unit is resolved, the user can return to normal operation by pressing the F2 key twice to return to AutoSegue mode. By default, the environmental variable is unset. If it remains unset, the following message is logged to the hard drive stanza of the DIALOG and UDS2BOOT.LOG files: "Stop mode not entered on catastrophic errors" On the other hand, if the user sets the value (shown below as "") to one within the range of 1 through 100, inclusive, the following informational message is written: "Stop mode entered on catastrophic error(s)" HD_CATASTROPHIC_REF BOOLEAN UNSET - If using a DPMI version (2.22v or greater) of the UDS II software, the user may optionally set this environmental variable to a value of 1. If thusly set, each consecutive failure to load a cart results in the incrementing of an internal "catastrophic" failure counter. Setting this variable is directly dependent upon HD_CATASTROPHIC_FAIL also being set. In other words, this ENV does nothing unless HD_CATASTROPHIC_FAIL is set to an allowable value. The intent is to guard against "chewing through" a schedule caused by consecutive failures to load carts, much like CDK3600_LOAD_FAIL will force the system into emergency stop mode when there are consecutive load failures. - The default behavior is not to "count" a cart load failure as a catastrophic error. Consequently, the following is logged to both DIALOG and UDS2BOOT.LOG: "Missing carts will NOT increment catastrophic failure counter" - However, if HD_CATASTROPHIC_REF is set to a value of 1, the following message is logged in the hard drive stanza of the aforementioned files: "Missing carts will increment catastrophic failure counter" - If HD_CATASTROPHIC_FAIL is unset, neither message appears because of the ENV dependency. RSHD_IGNORE_STOP_SIGNAL BOOLEAN UNSET The user may now optionally set this environmental variable to control an aspect of the UDS II's failure handling system when used with RS-HD. If unset (the default case), UDS II will immediately enter emergency stop mode when it receives a "termination" signal from RS-HD. This happens regardless of what event is currently airing. Setting this ENV disables this behavior. Upon receipt of such a termination signal, UDS II will continue to attempt to run in spite of RS-HD being down. It is strongly suggested that this variable not be set in order to take advantage of the protection it gives. If the user insists on leaving this unset, it is suggested that HD_CATASTROPHIC_FAIL be set to a reasonable value as a safety net. The state of the environmental variable is logged to DIALOG and to UDS2BOOT.LOG and is shown by one of the following messages: "Stop mode entered on RS-HD termination signal" <- default "Stop mode NOT entered on RS-HD termination signal" RSHD_CUT_INFO BOOLEAN UNSET The UDS II now "reveals" that cart number in the following ways (presuming this environmental variable is set to a value of 1): 1). On the UDS II's main screen, in the On Air, Next to Air or Next to Follow box. The 4-character cart identifier is appended with a dash followed by the zero-padded two-digit cut number. 2). In the F4 editor. The 4-character cart identifier is also appended with a dash followed by the zero-padded two-digit cut number. 3). In the following logging files: UDSLOG and AFFIDAV. There are a several caveats that must be noted: a). The cut number is "revealed" only when the cart has been resolved by the QUEUE CART routine. This means that that cut number will only be shown (for 1 and 2, above) when the cart is in a "ready to play" state. b). The "revealing" of the cut number is not applicable to "first class" music (MOHD) items. This is not a severe limitation since the primary intent of using rotating carts (known also as subcarts) is for commercials, liners, jingles and other non-music items. c). The format of the AFFIDAV (affidavit log) now becomes incompatible with all prior versions if this feature is enabled. The reason is that the fixed-column format of the affidavit report was originally designed for a cart identifier of exactly 4 characters. The addition of a cut number now slides everything over by 3 characters to include the dash and the zero-padded 2-digit cut number. This is a factor that automated reconciliation parsers will have to take into account. d). This display of the cut number is "read-only". The fact that it shows up in the F4 editor does not mean that one may explicitly alter the rotation scheme of a multiple cut cart. For the sake of backward compatibility and due to prior art the default is to not "reveal" this cut information. Resultantly, the following message is normally logged to the RS-HD stanza of the DIALOG and UDS2BOOT.LOG files: "Cut info will NOT be displayed for rotating carts" However, if the user has set RSHD_CUT_INFO to a value of 1 in the environment, the following message is written to the files: "Cut info will be displayed for rotating carts" RSHD_TIME_SYNC BOOLEAN UNSET Explicit false RSHD_TIME_SYNC UNSET Minute offsets - This environmental variable, available only on DPMI flavors of the UDS II version 2.29l or greater, equipped with RS-HD, will govern how the UDS II will attempt to set its time of day clock relative to that of the Linux-based RS-HD computer. - In the absence of any setting whatsoever of RSHD_TIME_SYNC, the UDS II will query the RS-HD at a compiled in default time offset starting at 25 minutes past every hour. - If the value of RSHD_TIME_SYNC is set to any of the following boolean false values (without regard to case), any attempt by the UDS II to adjust to or from the time of the RS-HD box will not occur: FALSE, NO, OFF. (In reality, any value assigned to this ENV that is non-numeric will equate to a boolean false in this context. It is recommended, though, that the user restrict the setting to one of the three shown above to better document what is going on). - On the other hand, a list of up to 5 comma separated values will cause the UDS II to attempt to synchronize its time of day clock at the minute specified by each of the values. Consider the following example: RSHD_TIME_SYNC=10,30,50 This will cause the UDS II to communicate with the RS-HD each hour at 10, 30 and 50 minutes past the hour, every hour in order to synchronize the time. * Since there is the potential for a lot of serial communication between the UDS II and RS-HD (particularly while handling QUEUE cart commands), the UDS II will wait for an opportune time to sync the clock after reaching the specified minute offset. That "opportune time" is defined as a window spanning at least 5 seconds into the currently airing event and with at least 10 seconds remaining on that airing event. This window spanning is performed only if the airing or next to air event is from an RS-HD source. This means, for example, that a synchronization specified at 10 minutes past the hour may be deferred until until some opportune moment past that specified the user. * The syntax of the comma-separated list is very strict. 1). There is to be no whitespace whatsover in the list. 2). When using this ENV to specify such minute offsets, valid characters consist solely of digits and commas. No alpha characters are permitted. 3). A trailing comma is not permittted. 4). The offsets specified must be within the range of 0-55 [sic], inclusive. 5). Furthermore, there must be more than a 5 minute separation between each sync time. 6). No more than 5 values can be specified. Anything after the fifth one will be ignored. - Here are valid examples of the syntax: RSHD_TIME_SYNC=10,30,50 RSHD_TIME_SYNC=5,35,45,55 RSHD_TIME_SYNC=05,25,45,55 RSHD_TIME_SYNC=10,20,30,40,50 RSHD_TIME_SYNC=15,45 RSHD_TIME_SYNC=30 - Here are valid examples of the syntax: RSHD_TIME_SYNC= 10,30,50 [ leading space ] RSHD_TIME_SYNC=5, 25, 45 [ embedded spaces ] RSHD_TIME_SYNC=5,25,95 [ obvious invalid value ] RSHD_TIME_SYNC=5,25,59 [ subtle invalid value ] RSHD_TIME_SYNC=5,25,45, [ trailing comma ] RSHD_TIME_SYNC=5 25 45 [ not comma delimited ] RSHD_TIME_SYNC="5,25,45" [ quoted list is invalid ] RSHD_TIME_SYNC=5,10,15,20 [ separation not sufficicient ] RSHD_TIME_SYNC=5,15,25,35,45,55 [ too many items ] ==================================================================== III. Here is a summary of ENVs dealing with RBDS: ------------------------------------------------------------ ENV NAME VALUE Default Units ------------------------------------------------------------ UDS2_RBDS DCI_BROADCAST (None) Text string FLASHCOMM (None) Text string LA_BELLE_SIGN (None) Text string ASCII (None) Text string STREAMAUDIO (None) Text string INOVONICS_711 (None) Text string - MUST BE SET TO EXACTLY ONE OF THE SIX (6) VALUES SHOWN ABOVE. This setting determines which one of the RBDS units is in use. This value portion of the string *is* case-sensitive, so that, for example, "ASCII" is correct but "Ascii" is not. Likewise, "STREAMAUDIO" is correct but "StreamAudio" is incorrect. * Although there are "standards" for the various types of RBDS units, the adherence (or lack thereof) to the standards is such that each individual unit requires an explicit environmental variable specific to that unit. - Note that support for the "INOVONICS_711" type is supported for versions of the UDS II starting with 2.33sN or later. It is a DPMI-only feature. As is the case with all RBDS-related types, the serial port is hard-coded as COM1 (IRQ 4, address 0x3f8). The output speed is hard-coded at 9600 bps. The speed can be adjusted via the UDS2_RBDS_SPEED environmental variable, which is explained below. - Note that support for the "STREAMAUDIO" type is supported for versions of the UDS II starting with 2.33eN or later. It is a DPMI-only feature. As is the case with all RBDS-related types, the serial port is hard-coded as COM1 (IRQ 4, address 0x3f8). The output speed is hard-coded at 2400 bps. Just millseconds after each new events starts (at segue time), the following text string is written to the serial port: "Title Info\fArtist Info\fMMM:SS\fCart and Cut #\fT\r\n" * A formfeed character delimits each field. * A carriage return/newline pair delimits each packet. * The duration of the event is represented as a zero-padded value using MMM:SS notation. * The "T" element shown above is either 'M' for music or 'C' for anything else. - Note that support for the "ASCII" type is, as of this writing on 4 December 1998, available only as an internal release. It has not been tested by anyone other than the developer. Applicable only to DPMI versions of the software, if UDS2_RBDS is set to ASCII (case-sensitive), the format of the data transmitted to COM PORT 1 (at 9600, N/8/1) conforms to the "Generic RDS/DAB output" style specified by On Air's Bernhard Dreyer in e-mail directed to JFS dated 27 November 1998. Specifically, there is a trio of double-quote-delimited, comma-separated strings following this format: "","",""\r\n ...where is the user defined text (up to 70 characters) in the F8 "System Info/RBDS" window. ...where is the artist followed by an ellipsis and the title of the event in the "On Air Box". ...where is the artist followed by an ellipsis and the title of the event generally in the "Next to Air Box". Also note the reference (below) to UDS2_RBDS_MIN_LENGTH, which determines the minimum length an event must be in order to qualify as either the or . a). The maximum length of the RS-232 string is 250 characters, including the terminating "\r\n" sequence. Longer strings are simply truncated (but do include the "\r\n" terminator). b). The string are transmitted at the default of 16-second intervals or at the first opportune time after a segue has occurred. "Opportune time" means that a string will be transmitted 1.5 seconds after a segue...so long as a previous string wasn't transmitted within 1.5 seconds. The interval between transmission of the data can be set to a value other than 16 seconds by adjusting the UDS2_RBDS_DELAY environmental variable. c). The two meta-characters (double-quote and comma) are escaped with a backslash if they are part of the ordinary text. All other characters are transmitted without alteration. d). Unlike the DCI Broadcast, FlashComm and LaBelle sign devices, the UDS II does not restrict its transmissions to "music-only" information. The text of all airable (non-system) events is transmitted to the serial port, as long as the duration (length) of that event is greater than or equal to that specified by UDS2_RBDS_MIN_LENGTH. e). If the user has set UDS2_RBDS=ASCII, the "RBDS parameters" stanza of both the DIALOG and UDS2BOOT.LOG files will show a line resembling this: "4:18:11 PM Unit: Generic RDS/DAB (ASCII)" UDS2_RBDS_SPEED 1200-19200 (Varies) BPS Presuming that the UDS II version is 2.33p or greater, the value for UDS2_RBDS_SPEED can be set to any of these numbers: 1200, 2400, 4800, 9600 or 19200 In the absence of this environmental being set, the following defaults prevail: RBDS Type COM port speed (bps) --------- -------------------- DCI_BROADCAST 9600 FLASHCOMM 9600 LA_BELLE_SIGN 9600 ASCII 9600 STREAMAUDIO 2400 INOVONICS_711 9600 * Note: If UDS2_RBDS_SPEED is set to a value other than 1200, 2400, 4800, 9600 or 19200, the default value for the RBDS type will be used. Regardless of whether the COM port speed is set by default or explicitly by UDS2_RBDS_SPEED, a message such as the following is written to both the DIALOG and UDS2BOOT.LOG files: 4:17:49 PM RBDS parameters: [...] 4:17:49 PM IRQ $04, Address: $03F8 4:17:49 PM Communications speed: 2400 bps UDS2_RBDS_DELAY 1-5000 16 Seconds (DCI) 16 Seconds (FlashComm) 16 Seconds (ASCII) 3 Ticks (LaBelle) - Amount of time to delay between transmission to the RBDS unit, expressed as a length (in ticks) between characters for the LaBelle "Info Express" sign or a delay time (in seconds) between each full message for either the DCI Broadcast or FlashComm units. UDS2_RBDS_PI 1-FFFF (None) Hex string - MUST BE SET FOR DCI_BROADCAST! Although a probable obsolescent feature, the PI setting must be set for DCI Broadcast. If in doubt about the PI setting, set it to 2020. It is ignored if UDS2_RBDS is set to either FLASHCOMM or LA_BELLE_SIGN. UDS2_RBDS_UP_NEXT 1-5000 55 Seconds - Amount of "countback time" before the "COMING UP NEXT" message is transmitted. A reasonable non-default value might be 160 which means that 2:40 from the end of the current on-air event, the "COMING UP NEXT" message will be interleaved with the standard RBDS text rotation. UDS2_RBDS_PADCHAR (Character) ASCII Character : This applies ONLY to the DCI Broadcast unit. The LaBelle "Info Express" sign's space pad character is a hard-coded value. There is no padding required for the FlashComm unit. : Refer to text below for default pad characters. - Character to be prepended and appended as fill character to "center" the text to be transmitted to the RBDS unit. For instance, in the case of the 64-byte buffer employed by DCI Broadcast, an appropriate number of these fill characters will surround the text to ensure that it is exactly 64 characters in length. As noted above, the default character is a space ( ) for the LaBelle sign and a dot (.) for the DCI Broadcast unit. As UDS II version 1.75i, the padding environmental variable may now optionally be set using single-quote-style notation. This permits the user of a DCI Broadcast unit to explicitly set the pad character to a single space (as opposed to the default of a dot) via the following command: SET UDS2_RBDS_PADCHAR=' ' Note that for any other character, this form of quoting is not necessary. UDS2_RBDS_TA_CART (Characters) 4 character ASCII string - Available only if the Flash Comm or Inovonics 711 device is used (as set by UDS2_RBDS=FLASHCOMM or UDS2_RBDS=INOVONICS_711. This setting enables support for "traffic announce" carts. The user should set UDS2_RBDS_TA_CART= where is a case-sensitive four character cart identifier conforming to a DCS, RS-HD or AV100 cart naming convention. If thusly set, each time that cart begins airing, the UDS II will transmit the string, "TA=ON" to the appropriate RBDS unit. After that cart finishes, the string "TA=OFF" will be transmitted. During the airing of that designated "TA" cart, the "radio text" cycle still continues. This means that the rotation between "COMING UP NEXT:" and the user-defined RBDS logo will be transmitted if time permits (as set by the user via UDS2_RBDS_DELAY). As of UDS II version 2.12z, if a DCS unit is used for digital audio, a cart identifier corresponding to that of UDS2_RBDS_TA_CART will also send "TA=ON" to the Flash Comm or Inovonics 711 RBDS unit if played from the "hotkey window". The string "TA=OFF" will be transmitted when an "EE" (EOF) is received from the RS-HD or DCS or when the user explicit halts that cart from the "hotkey" window. UDS2_RBDS_MIN_LENGTH 1-3600 10 Seconds - Available only if the DPMI version of the UDS II is configured to use the "ASCII" style RBDS output, this value determines the minimum length (duration) that an event must be in order to qualify as either or . If a has a duration less than this value, it causes a deferral of a transmission until a segue occurs with an event's duration >= UDS2_RBDS_MIN_LENGTH. In the case of , UDS II's internal array of airable events is scanned from the next to air position until 30 events ahead of currency until a event is found with a duration >= UDS2_RBDS_MIN_LENGTH. This allows the user to specify a "cutoff length" that results in the UDS II bypassing the transmission of text for short jingles, for instance. The value for this variable is logged to both the DIALOG and UDS2BOOT.LOG file (in the "RBDS parameters" stanza) as per this example: "4:18:11 PM RBDS event minimum length: 32 seconds(s)" ==================================================================== IV. Here is a summary of hardware-related ENVs. WARNING: These are not recommended to be changed unless instructed by On Air USA: ------------------------------------------------------------ ENV NAME VALUE (Default preceded with *) ------------------------------------------------------------ UDS2_SWITCHER BT6X1 BT10X1 - Specifies type of switcher/router used by the UDS II, RS-232 serially controlled (which requires setting both of the ENVs: UDS2_RS232_3RD_IRQ and UDS2_RS232_3RD_ADR). There is no default value and the internal string validation is done without regard to case, although there must be no whitespace in the value string. BT6X1 - specifies Broadcast Tools 6x1 Passive Switcher/Router BT10X1 - specifies Broadcast Tools 10x1 Passive Switcher/Router - If one of the above two values is correctly specified by the ENV, the following behavior results: 1). A check is then made to ensure that both UDS2_RS232_3RD_IRQ and UDS2_RS232_3RD_ADR are set to accepted values. If not, nothing further happens. Otherwise, the following items prevail: 2). Sources 71 and 72 are accepted as bonafide system commands both within the context of the UDS II F4 editor and as schedule import items. - If BT6X1 is set, the following numbers are allowed for input channel enable values: 1, 2, 3, 4, 5 and 6. - If BT10X1 is set, the following numbers are allowed for input channel enable values: 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10. * In both cases (BT6X1 and BT10X1), the character 'm' or 'M' is accepted as a global mute command. 3). The optional number specified as part of the "simple network recording" system command (source 80) is treated as an input channel to turn on (rather than as a relay to fire). 4). One of the following message is written to both the DIALOG and UDS2BOOT log files, depending upon the value set by the user for UDS2_SWITCHER: UDS II switcher info: Broadcast Tools 6x1 Switcher/Router [Serial params text] UDS II switcher info: Broadcast Tools 10x1 Switcher/Router [Serial params text] 5). The UDS II communications speed is fixed at 2400 bps. This can't be adjusted on the UDS II side. Depending upon the age of the Broadcast Tools switcher, it may require setting a dip switch to force the speed to 2400 bps. UDS2_RECORDING_RELAY UNSET BOOLEAN - When set to a value of 1, this forces a utility relay to be associated with the "simple network recording" command even if the system is otherwise configured to take advantage of the more flexible means of controlling an external audio switcher/router via serial control. If set, the following line appears in the "UDS II switcher info" stanza of the DIALOG and UDS2BOOT logging files: "Recording command 80 uses switcher: NO" If unset, and a switcher is properly configured, the following is the default message: "Recording command 80 uses switcher: YES" Note that this enviromental variable is only meaningful when the UDS II is configured to use an external switcher. If this environmental variable is set without such an external switcher being configured, it is ignored. UDS2_RS422_IRQ 2 3 4 5 *7 10 11 12 15 - RS-422 IRQ in decimal. UDS2_RS422_ADR $238 *$278 $2B8 $2F8 $338 $378 $3B8 $3F8 - RS-422 port base address in hex. UDS2_RS422_XMIT_TIME 2 *3 4 5 6 - This value, expressed in timer ticks, determines how long the UDS II will wait for confirmation of transmission of characters via RS422 before timing out. Note that the default value is 3 ticks...but there may be circumstances where this value should be incrementally adjusted upward. Please do not change this value unless there are frequent instances of error messages containing the text: "...timeout (Xmit422)-..." or "...timeout (XmitChar)..." If a Denon CD player is detected in the equipment file during UDS II startup, the default transmit time value increases to 4 ticks (instead of 3). UDS2_RS422_RCV_TIME 5 6 *7 8 9 10 11 12 - This value, also expressed in timer ticks, determines how long the UDS II will wait for receipt of a reply via RS422 before timing out. Note that the default value is 7 ticks...but there may be circumstances where this value should be incrementally adjusted upward. Please do not change this value unless there are frequent instances of error messages containing the text: "...timeout (Xmit422)-..." or "...timeout (XmitChar)..." - Note that the current values of both UDS2_RS422_XMIT_TIME and UDS2_RS422_RCV_TIME are logged to the DIALOG and UDS2BOOT.LOG files as follows: "RS422 Xmit Time: 3, Rcv Time: 7" - Also note that user-defined value outside of the range indicated above causes the default value to go into effect. If a Denon CD player is detected in the equipment file during UDS II startup, the default transmit time value increases to 10 ticks (instead of 7). UDS2_RS232_IRQ *3 4 5 9 10 11 12 13 15 - RS-232 IRQ in decimal. If used in a "Dual DigAudio" setting, this sets the IRQ for serial communications with the RS-HD. The default IRQ then becomes 4 instead of 3. UDS2_RS232_ADR $2E8 *$2F8 $3E8 $3F8 - RS-232 port base address in hex. If used in a "Dual DigAudio" setting, this sets the IRQ for serial communications with the RS-HD. The default address then becomes $3F8 rather than $2F8. UDS2_RS232_2ND_IRQ *3 4 5 9 10 11 12 13 15 - RS-232 IRQ for second serial port in decimal. This sets the serial communications address for a DCS when used in a "Dual DigAudio" environment. UDS2_RS232_2ND_ADR $2E8 *$2F8 $3E8 $3F8 - RS-232 port base address for second serial port in hex. This sets the serial communications address for a DCS when used in a "Dual DigAudio" environment. UDS2_RS232_3RD_IRQ 3 4 5 9 10 11 12 13 15 - RS-232 IRQ for "third" serial port in decimal. At present, this sets the serial communications address for a Broadcast Tools Switcher/Router. Note that no values are assigned by default. * The communications speed is fixed at 2400 bps and can't be altered on the UDS II side. UDS2_RS232_3RD_ADR $2E8 $2F8 $3E8 $3F8 - RS-232 port base address for "third" serial port in hex. At present, this sets the serial communications address for a Broadcast Tools Switcher/Router. Note that no values are assigned by default. * The communications speed is fixed at 2400 bps and can't be altered on the UDS II side. UDS2_HD_BAUD 1200 2400 4800 9600 19200 *38400 57600 115200 - RS-232 baud rate for RS-HD only, defaulting to 38400. * Support for 57600 is available only with RS-HD version 00.11t or greater with UDS II version 2.30g or greater. * Support for 115200 is available only with RS-HD version 00.12f or greater with UDS II version 2.30i or greater. UDS2_EPROM_ADR $238 $278 *$2B8 $2F8 $338 $378 $3B8 $3F8 - UDS2's EPROM base address in hex. UDS2_8255_ADR $200 $210 *$300 $310 $380 $390 - 8255 PPI chip's base address in hex. UDS2_8255_OFF *$0 $4 $8 $C - 8255 PPI chip's offset from base address in hex (see above). ==================================================================== V. Here is a summary of all ENVs that are related to tunable parameters for any UDS II supported CD player: ------------------------------------------------------------ ENV NAME VALUE Default Units ------------------------------------------------------------ CDK3600_LOAD_FAIL 1-50 (NONE) Failure count - If CDK3600_LOAD_FAIL is set to an allowed value, the system will go into an "EMERGENCY STOP" condition once the number of CDK-3600 deleted events exceeds the user-defined value as set in the ENV. The user is alerted to such a condition by noting that the system automatically went into STOP mode and is accompanied by an on-screen flashing yellow on red message: "EMERGENCY: * CDK-3600 load fail exceeded, stopping UDS2 *" Once the problem with the Sony CDK-3600 is rectified, the user can return to normal operation by pressing the F2 key twice to resume AutoSegue mode. CDK3600_TC_RETRY 1-25 1 No time code retry count - When CDK3600_TC_RETRY (the "TC" stands for "time code") is set to a value greater than the default of 1, a segue code of 31 will *not* be issued until the number of consecutive instances of a "no time code" failure is met or exceeded. Presuming this value is set to, say, 5, here's a scenario of what would happen at runtime on any given compact disc playing from a Sony CDK-3600 unit: * Upon encountering the first failure of "no time code", an internal counter is set to 1. At this point, the system continues to air that CD, but issues the following example "warning" level message to the screen and to the DIALOG file: "6:43:02 PM [1/5] CDK-3600 no time code: 1163-04 ($00)" a). "6:43:02 PM": the time of the incident b). "[1/5]": '1' is the *current* count of "no time code" failures and '5' is the value set by CDK3600_TC_RETRY. c). "1163-04" is the CD disc and track d). "($00)" is a hexadecimal response code from the CDK-3600 unit. The number may be something other than $00 and is of value only for On Air USA diagnostic purposes. * Each subsequent consecutive "no time code" failure increments an internal counter. When (and if) that counter meets or exceeds the value specified by CDK3600_TC_RETRY, the system then emits a segue code of 31 to attempt to play the next event. This is accompanied by the following "error" level message shown on the screen and written to DIALOG: "6:43:20 PM ERROR: 31 [5/5] CDK-3600 no time code: 1163-04 ($00)" The individual elements of the message are the same but, in this case, since a segue was forced by the system -- it is accompanied by ERROR 31 (the same value of the segue code). Also note that "[5/5]" indicates that there have been 5 consecutive failures of 5 permitted. * IMPORTANT: The "no time code" failure counter is not accumulated over the span of a given event's play. Instead, once valid time code information is re-established, the counter is reset to 0. Thus in the example case wherein CDK3600_TC_RETRY was set to 5, a segue will occur only when there have been 5 (or greater) cases of a "no time code" returned by the CDK-3600 in succession. In other words, over the course a song with a runtime of 3:30, there can be 5 such instances of "no time code" failures spread out over the duration of the song. As long as the "no time code" condition is not pathological, the song will continue to air -- but each case of a "no time code" failure will be logged for informational purposes. If this value is set to greater than 5, much debugging information will be written to the DIALOG file whenever an invalid time code string is returned. This information shows the length of the reply buffer and the full time code string. An invalid time code string is one with a length of less than 9 characters or with the status byte other than 0xF0 or 0xF1. CDK3600_TRACK_RETRY 1-25 1 Track change indicator count - When CDK3600_TRACK_RETRY is set to a value greater than the default of 1, a segue code of 32 will *not* be issued until the number of consecutive instances of a track change indicator is met or exceeded. Presuming this value is set to, say, 3, here's a scenario of what would happen at runtime on any given compact disc playing from a Sony CDK-3600 unit: * Upon encountering the first indication of track change, an internal counter is set to 1. At this point, the system still continues to air that CD, but issues the following example "warning" level message to the screen and to the DIALOG file: "6:43:02 PM [1/3] CDK-3600 track change: 1163-04" a). "6:43:02 PM": the time of the incident b). "[1/5]": '1' is the *current* count of the track change indicator and '3' is the value set by CDK3600_TRACK_RETRY. c). "1163-04" is the CD disc and track * Each subsequent consecutive track change indicator increments an internal counter. When (and if) that counter meets or exceeds the value specified by CDK3600_TRACK_RETRY, the system then emits a segue code of 32 to attempt to play the next event. This is accompanied by the following "error" level message shown on the screen and written to DIALOG: "6:43:20 PM ERROR: 32 [3/3] CDK-3600 track change: 1163-04" The individual elements of the message are the same but, in this case, since a segue was forced by the system -- it is accompanied by ERROR 32 (the same value of the segue code). Also note that "[3/3]" indicates that there have been 3 consecutive failures of 3 permitted. * IMPORTANT: The track change indicator counter is not accumulated over the span of a given event's play. Instead, once valid time code information corresponding to the currently airing track is received, the counter is reset to 0. Thus in the example case wherein CDK3600_TRACK_RETRY was set to 3, a segue will occur only when there have been 3 (or greater) cases of track change indicators returned by the CDK-3600 in succession. In other words, over the course a song with a runtime of 3:30, there can be 3 such instances spread out over the duration of the song. As long as the track change indicator condition is not pathological, the song will continue to air -- but each case of this track change indicator will be logged for informational purposes. (Not logged to screen, but written to the DIALOG file for diagnostic purposes is the complete time code string assembled by the Sony CDK-3600 handler. Although its value is primarily for On Air USA technicians, a "short" string containing fewer then the expected characters is of great help in isolating CD player problems). Much like CDK3600_TC_RETRY, if this value is set to greater than 5, much debugging information will be written to the DIALOG file whenever an invalid time code string is returned. This information shows the length of the reply buffer and the full time code string. An invalid time code string is one with a length of less than 9 characters or with the status byte other than 0xF0 or 0xF1. (Note that *either* of the retry values set to greater than 5 iterations will cause the extensive logging). CDK3600_VERBOSE BOOLEAN UNSET - When CDK3600_VERBOSE is set, much detailed diagnostic information is written to the DIALOG file. The state of the RS422 is written as well as certain status bytes values returned by the CDK-3600 player. Because this information can consume a lot of lines in the DIALOG file, it should remain unset unless directed otherwise by On Air USA. The content of the data has little value for most clients and is intended for analysis by authorized On Air USA personnel. UDS2_NAK_TIMEOUT 1-600 10 Seconds before segue - Note that the default value is 10 seconds, but that it may be set to anywhere within the range of 1 through 600 seconds (10 minutes). If the value set by the user is outside of this range, the default of 10 seconds is used. This variable governs at what point a segue code 33 will be issued by the UDS II when a series of NAK responses if received while a Sony CDK-006, NSM3101AC or Denon 1400 CD player is airing a compact disc. If such a series of NAKs (not acknowledge) responses is received and the current elapsed time is UDS2_NAK_TIMEOUT greater than the database time for the currently airing CD event, a segue code 33 is issued. Along with this "failsafe" segue comes the following error message, displayed on the main screen and also written to DIALOG: "CD Player # NAK segue on " It likely means that the error condition is unrecoverable and, as a result, a segue is forced to avoid possible dead air. This segue code only occurs with the Sony CDK-006, NSM3101AC and Denon 1400 units. UDS2_LOAD_PROTECT 1-10 UNSET "Look around" count - NOTE: This value, if set, is active only during the time that UDS II is operating in "Auto Segue" mode. The presumption is that if the system is in "Live Control" mode, an operator is on hand to deal with CD player load errors. - Normally, the UDS II deals with a CD player load error by: a). Removing the errant event from the schedule. b). It then looks at the source number of the event now occupying the position of the failed event. c). Then it compares that source number with the event immediately before the event it found in step b). d). If there is a source conflict (that would lead to back-to-back play), the UDS II removes that event (the one found by b) as well as the one it was unable to load. Note that the UDS II does not do any "look around" to determine if there are intervening non-music events that still may lead to an "indirect" back-to-back situation. - Setting UDS2_LOAD_PROTECT to a value between 1 and 10 (inclusive) means that the UDS II will scan up to that many events to determine if a conflict will arise. During the scan, it keeps track of the accumulated runtime of intervening non-music events. 1). If the accumulated runtime is sufficient to permit an otherwise "conflicting" CD player to reload, nothing else is done (beside removing the unloadable CD disc from the schedule). 2). If the accumulated runtime is not sufficient to permit a CD reload to occur, the CD discs that would lead to the conflict is also removed from the schedule. This is logged to DIALOG as per this example: "Loading error removed 2018-99 and 226-11" The first CD identifier is the "unloadable disc" and the second is the one that was removed to resolve a potential back-to-back conflict. The latter CD is also logged to the DROPSONG file along with the message "Back-to-back conflict". UDS2_DENON_VERBOSE 1-2 UNSET LEVEL - When UDS2_DENON_VERBOSE is set, much detailed diagnostic information is written to a file named DENONDRB. (where is the zero-padded monthday) in the UDS II's logging directory, generally C:\UDS2\LOGGING. The file contains a log of RS-422 traffic flowing between the UDS II and the Denon 1400 interface. Because this file can grow to a multi-megabyte size very quickly, it is suggested that this variable only be enabled at the explicit direction of On Air USA. As of UDS II version 2.12a, the "verbosity" of the diagnostic information can be currently be set to a level of from 1 to 2. If UDS2_DENON_VERBOSE=2, all RS-422 communication between the UDS II and the Denon is logged. However, if the user sets UDS2_DENON_VERBOSE=1, time code data is not written to the diagnostic file. If this environmental variable is not set, no such diagnostic information is written at all. Note that, even without the logging of time code data, the files can grow to a large size (depending upon the amount of traffic flowing on the RS-422 line). As a result, the diagnostic information is written only if the UDS II detects that there's at least 15 mB free prior to each write. The status of UDS2_DENON_VERBOSE is logged to the Denon stanza of the DIALOG and UDS2BOOT.LOG files as one of the following: "Verbose logging: enabled at level: 1" "Verbose logging: enabled at level: 2" "Verbose logging: disabled" UDS2_DENON_WAIT_BEFORE_LOAD 180-500 275 TICKS Setting UDS2_DENON_WAIT_BEFORE_LOAD to a value between 180 and 500 (inclusive) determines at what point the load sequence will be initiated for a Denon 1400 CD player after a stop command was successfully sent. The UDS II's loading sequence for a Denon 1400 always begins with a stop command (to ensure that player to be loaded will be "free and clear" of a mounted disc). Once the stop command has been accepted, a timer is set within the UDS II to create a lag between the receipt of the stop acknowledgment and when the load sequence can occur. This value's rather high default of 275 ticks (which is about 15 seconds) will cause the load initiation to be deferred until the stop has likely been carried out to completion. - Note that the number of seconds for a tick value can be determined by dividing by 18.2 (because PC's produce that many ticks each second). Therefore, the permissible wait time range is from 10 seconds to about 27 seconds. - It is strongly suggested that this setting not be changed unless explicitly advised to do so by On Air USA. - If the variable is set to an "out of range" value, the default of 275 ticks (15 seconds) is used. UDS2_DENON_TC_STUCK 0-200 30 "Time code" count Setting UDS2_DENON_TC_STUCK to a value between 1 and 200 (inclusive) determines how many consecutive instances of repeated time code strings will be accepted before a segue 042 is issued by the UDS II. If a CD player time code value stays constant over a period of repeated polling, it likely means that the disc is, in fact, "stuck". Because there are occasions when the CD player may not actually be sticking (but the time code value doesn't increment), the user is given the opportunity to adjust this threshold value to a range between 1 and 200. The default value of 30 means that if there are 31 consecutive instances of the same time code string returned when the player is queried, a segue code of 42 will be issued to advance to the next event. Setting this value to 0 is a special case. It means that the user elects to ignore any and all instances of such repeated time code values. Caveat emptor. If set to 0, the UDS II may allow a disc that is legitimately stuck to continue to play for an undetermined amount of time. The current value of this variable is logged to both DIALOG and UDS2BOOT.LOG as per the following example: "Denon1400 stuck count threshold: " UDS2_TRACK_CHANGE_TIME 0-59 3 Time (in seconds) Setting UDS2_TRACK_CHANGE_TIME to a value between 1 and 59 (inclusive) causes the UDS II to ignore a possibly suspect "track change" if it occurs within the timespan set by the user. - Note that setting it explicitly to a value of 0 make the UDS II act immediately on a track change indication, even if it occurs right after the song started. - As of version 2.07v of the UDS II software, the default value (as shown above) was changed from 0 to 3, to decrease the possibility of premature segues caused by what, in fact, may be errant track change indicators. For example, if a "track change" indication occurs when a given CD song has been playing for 15 seconds but the user has set UDS2_TRACK_CHANGE_TIME to 20, the "track change" indication will simply be ignored. If a "track change" indication is received by the UDS II after the song in question has been playing for more than 20 seconds, a segue code 32 will be issued by the system because the elapsed time is beyond the threshold value. It is recommended that this value be set to the lowest possible yet realistic value. The receipt of a "track change" may be valid (perhaps because a badly skipping CD). However, it's apparent that a "track change" indication that occurs within a few seconds of the start of a CD is likely in error. A suggested value for this variable is 15. This means that a "track change" indicator will be acted on only after the song has played for at least 15 seconds. If UDS2_TRACK_CHANGE is set to a valid value (1 through 59 seconds), the following message is written to the DIALOG file's startup stanza: "CD player track change threshold time: seconds(s)" UDS2_DENON_D1_COUNT 1-20 5 Iterations For pathological cases of errant premature segues, the user may set this threshold to a value of his/her choosing. The environmental variable is UDS2_DENON_D1_COUNT. The "D1" refers to the "end of track indicator" transmitted to the UDS II via the interface firmware when it detects an end of track condition. This environmental variable may be set to a value ranging from 1 through 20, inclusive. If unset, the default of 5 is used. UDS2_DENON_NO_D1_RELOAD BOOLEAN UNSET - If set to a value of 1, a "D1" response during a Denon load query is simply ignored and no attempt is made to reload the unit. Both DIALOG and UDS2BOOT.LOG show the status of how the UDS II in this regard by logging one of the following messages: "Will reload on D1 receipt" -or- "Will NOT reload on D1 receipt" If unset (the default), exactly one attempt is made by the UDS II to reload the disc onto the Denon CD player if a "D1" response is received during the load query phase. UDS2_DENON_NO_D1_STOP BOOLEAN UNSET - NOTE: UDS2_DENON_NO_D1_STOP is available for diagnostic purposes only. This should NEVER be set by the user unless explicitly instructed to do so by On Air USA. - If set to a value of 1, a "D1" response during a pre-stop query by the UDS II to the Denon 1400 means that an explicit stop command will NOT be transmitted to the Denon. The presumption is that a "D1" indicates that the Denon is in a state of quiescence and need not be stopped. Experience has shown otherwise. There has been at least one occasion where a "D1" is reported back when a disc is mounted on the player. As a result, the default behavior of the UDS II is to send an explicit stop even if the Denon reports that the player is quiescent. The behavior of the UDS II in terms of a stop command is logged thusly to DIALOG and to UDS2BOOT.LOG in the Denon stanza: "Will send stop command on D1 receipt" (Default) "Will NOT send stop command on D1 receipt" (If ENV is set) UDS2_DENON_LOAD_FAIL_RESET 0-10 3 Iterations - By default, a reset to a Denon CD unit will be sent after 3 consecutive load failures on that unit. Such consecutive load failures are defined as: a). No successful loads on that unit. A successful load resets the internal counter to zero. b). No instance of a track not found error. Although this is a load failure, it does indicate that the Denon is still responding in a proper manner. A cut not found condition also resets the internal counter to zero. c). At least one instance in a sequence of load failures of a "differing disc". In other words, if there are three consecutive load failures all involving the same disc, it is likely that the fault is with the physical CD rather than with the Denon unit. - The user may customize this parameter from its default value of 3. If set to 0, it disables this automatic reset command and the following message is written to the Denon stanza of both DIALOG and UDS2BOOT.LOG: "Will NOT reset Denon unit after consecutive load failures" Otherwise, if the value is non-zero, this message is logged: "Will reset Denon unit after consecutive load failures" - Note that if UDS2_DENON_LOAD_FAIL_RESET=1, a reset will be sent to the Denon once there's a single instance of a load failure so long as an event from that Denon unit is not currently on the air. - If an automatic reset is sent to the Denon because of a sequence of consecutive load failures, the following message is written to both the main UDS II screen and to the DIALOG file: "Denon unit # reset: consecutive load failures" ==================================================================== VI. Here is a summary of *all other* ENVs that impact other areas of UDS II operation (excluding those related to debugging): ------------------------------------------------------------ ENV NAME VALUE Default Units ------------------------------------------------------------ UDS2_VOICETRACK_FADE 1-10 9.9 Seconds [Real Mode] - or - UDS2_VOICETRACK_FADE -9.9 to 9.9 -0.1 Seconds [DPMI Mode] - If the UDS II's voice track system is enabled (via the F8 system configuration window), the user may optionally define this ENV to set the voicetrack fade rate. (Note that a user-defined value of 0 equates to a very quick fade rate of 0.1 seconds.) If the environmental variable is not defined or the value is outside of the range, the fade rate defaults to the legacy value of 9.9 seconds. * The support for voice tracking is confined to UDS II systems equipped with either a DCS or RS-HD. The enhanced form of voice tracking requires a DPMI version of the UDS II. If the user has so configured the UDS2 to permit such voice tracking support, the fade rate is written to the header of each DIALOG file as per: Voice track talkover level: -db , fade rate: where is the level set in F8 and is value possibly set through the UDS2_VOICETRACK_FADE environmental variable. This VOICETRACK_FADE value actually determines two things when used in the context of a voice track cart. 1). At what point the fade up starts. The fade rate value is subtracted from the song's intro time. Thus a 16 second intro time with a fade rate of 2.0 seconds results in a "fade up" starting at 14 seconds. 2). Per the example outlined above in 1), there will be a "slope" of 2.0 seconds (starting at 14 seconds) over which time, the A4000 will fade "up" from the value set by the user in F8 to normal level, 0 dB. NOTE: If using the DPMI version of the UDS II (version 2.02p) or greater, there's additional functionality "overloaded" into the setting of this environmental variable. First, the granularity of the "seconds" setting is not limited to whole (integral) numbers. This value can be set to a range of -10.0 through 10.0, affording a fine degree control over the fade rate when the "ramp up" occurs after a voice track cart concludes. Note that the default setting is as if the following were set: UDS_VOICETRACK_FADE=0.1 Second, and more significantly, the permissible values also include negative numbers. In reality, the negative values are converted to their absolute value to determine the "ramp up" rate. However, the negative number is a sentinel to change the behavior of the UDS II's handling of a voice over cart. If set to a negative value, the fade up of the pot occurs on receipt of EOF (this is not to be confused the "AUX mark", which is also known as EOM) from the voiceover cart. The value set by the user via UDS2_VOICETRACK_FADE determines the "rapidity" of the fade up rate. For tight-sounding "hot" station, a suggested value is simply the default of -0.1. This means that the pot for the music event will instantly -- but smoothly fade from its current value up to normal when the EOF arrives. Here's an example of what gets written to both DIALOG. and UDS2BOOT.LOG when the value is negative: "Voice track talkover level: -10db, fade rate: 0.5" "Events will fade up on EOF from voice tracks" However, if the value is set positive, the fade up doesn't start upon EOF receipt. Instead it works exactly as described in 1), above. Here's an example of what gets written to both DIALOG. and UDS2BOOT.LOG when the value is positive: "Voice track talkover level: -10db, fade rate: 2.5" "Events won't fade up on EOF from voice tracks" UDS2_NO_VOICETRACK_REMOVAL BOOLEAN Unset - If running a DPMI (protected mode) flavor of the UDS II software (version 2.08p or greater), the default behavior is to remove a voice track cart when the associated music element fails to load. Setting this ENV to a value of 1 overrides this default action...thus keeping the voice track cart in the schedule in spite of the load failure of the event associated with it. - If this environmental variable is set, the following message is written to both the DIALOG and UDS2BOOT.LOG files: "Voice track events won't be removed on load errors" On the other hand, the default message is: "Voice track events will be removed on load errors" UDS2_ROOT : "C:\UDS2\" (String) The user may now specify a root path other than the previously hard-coded "C:\UDS2\" UDS II root path. The environmental variable UDS2_ROOT should be set using *only* the form : where is a valid drive letter and is a fully-qualified path name of an *existing* directory. Case is not significant since the string will be forced to upper-case. The path should include exactly one trailing backslash -- but one will be appended if not. If the root path is found to be invalid, it reverts back to the standard "C:\UDS2\". UDS2_PREVIEW_RESPONSE 1-30 (NONE) Seconds - If UDS2_PREVIEW_RESPONSE is set to an allowed value, the system will handle the Alt-P music preview feature as follows: When the user has chosen a "cue into" point in the previewed music event (via the spacebar), the "cue into" point may optionally be used for the upcoming occurrence of that song. One the spacebar is pressed, an escape keypress is then required to elicit this prompt from the UDS II: "WARNING! Use this cue in?" If the user does not respond to this confirmation prompt within the timeframe established by the value of UDS2_PREVIEW_RESPONSE, the behavior is then equivalent to that of an escape press. (Note: In the event that UDS2_PREVIEW_RESPONSE is greater than the time remaining to segue to that song, the lower value is then used). UDS2_NO_F3_SEGUE_REFRESH BOOLEAN UNSET - If set, the system will *not* refresh the F3 (or Alt-F3) view screen when a segue occurs. This may be helpful for those clients wishing to use this feature when doing a backsell (since the normal behavior is to behave as though the "home" key were pressed on each segue). UDS2_NO_RELOAD_WARN BOOLEAN UNSET - If set, the system will *not* issue the following message when editing in the F4 window: "Insufficient time to reload, proceed anyway?" This message is designed to discourage users from modifying the schedule when a segue is about to occur. Although it is inadvisable to set UDS2_NO_RELOAD_WARN, there may be instances when this well-intentioned warning is undesired. Caveat emptor. UDS2_NO_FAIL_SAFE BOOLEAN UNSET - If set, the system will *not* take extreme measures to keep itself going under rare circumstances when the next event is not ready when a segue occurs. Note that the default behavior of "fail safe" operation is enabled only when operating in AutoSegue. There is no conceivable reason to set UDS2_NO_FAIL_SAFE other than for diagnostic purposes. Setting this ENV could lead to dead air that the fail safe mechanism will otherwise attempt to handle. Because this mode is not advised, the user will see "Fail safe mode disabled" in a red attribute in the F8 "System Info" window. UDS2_UPDATE_81 M:<1-10>[,<1-10>] UNSET - This ENV permits the user to "fine tune" the runtime behavior of time update 81. Note carefully the following examples of the syntax for setting this ENV, since it differs from all others. The examples will become clear once the remainder of this entire section is read. (OK) SET UDS2_UPDATE_81=M:1 (OK) SET UDS2_UPDATE_81=M:10 (OK) SET UDS2_UPDATE_81=M:8 (OK) SET UDS2_UPDATE_81=M:2 (OK) SET UDS2_UPDATE_81=M:1,1 (OK) SET UDS2_UPDATE_81=M:3,2 (OK) SET UDS2_UPDATE_81=M:1,10 (NOT OK) SET UDS2_UPDATE_81=M:1-5 (NOT OK) SET UDS2_UPDATE_81=M:11 (NOT OK) SET UDS2_UPDATE_81=1 (NOT OK) SET UDS2_UPDATE_81=1:M (NOT OK) SET UDS2_UPDATE_81=:1 (NOT OK) SET UDS2_UPDATE_81=:1;4 (NOT OK) SET UDS2_UPDATE_81=:1:5 (NOT OK) SET UDS2_UPDATE_81=:1,14 As of this writing, the user-defined value of UDS2_UPDATE_81 governs the *minimum* number of music events that must be determined as droppable by time update 81 before the update actually occurs. - There is an *optional* value that may be set to determine the amount of non-music elements. If this latter optional value is set, the actions described below are contingent upon there being at least that number of non-music events between the currently airing event and the update point. Analyzing the syntax of the user-defined value, the 'M' (note that it can also be lowercase, 'm') means "music", the ':' is a required delimiter and the following characters must represent a number in the range of 1 through 10 inclusive. - If the number (in the range of 1-10) is then followed by an optional comma and another value in the range of 1-10, the latter value sets the threshold value for the amount of non music events that must be encountered. If properly set per the syntax explained in the preceding paragraph (and in accordance with the examples above), when a time update 81 is about to be processed, the UDS II will perform an evaluation -- counting the number of music events eligible for deletion. If that count is less than the number specified by the "M:" value of UDS2_UPDATE_81, the update will not occurs and the following message is logged both to the UDS II screen and to the DIALOG file: "Time update 81 not performed, insufficient music events" VERY IMPORTANT: The sequence of the user's schedule may cause the evaluation to occur twice. Keen observers of the UDS II's update 81 process may have noted that an update 81 has the potential to occurs in two phases: 1). Initial evaluation: This is when a "what if" check occurs. If the update were to happen at this phase...and such an update would lead to a back-to-back source conflict, the update then goes into pending mode... 2). Pending mode evaluation: If the initial evaluation shows that a source conflict would result from the removal of events, the pending mode stays active through each segue. At each segue, the UDS II performs a re-evaluation to determine if the performance of the update would be "safe" in terms of affording back-to-back source protection. As a result of this multi-phased update process, it is suggested that the user set this ENV as follows: SET UDS2_UPDATE_81=M:1,1 Presuming the ENV is thusly set, here are how a couple of scenarios would play out: a). Src Event Status ---- ------- ------ 01 MUSIC A AIRING 02 MUSIC B NEXT TO AIR (LOADED) 09 :05 JINGLE NEXT TO FOLLOW 81 UPDATE AT 10:00 --- 01 MUSIC C --- At 10:00 past the hour, while MUSIC A is airing, the initial evaluation reveals that the update can't occur due to 01 to 01 source conflict with MUSIC A and MUSIC C. Time update 81 now enters pending mode and re-evaluates the situation when a segue occurs: 02 MUSIC B AIRING 09 :05 JINGLE NEXT TO AIR 81 UPDATE AT 10:00 --- 01 MUSIC C NEXT TO FOLLOW (LOADED) At this point, it is "safe" to perform the update because 02 (MUSIC B) to 01 (MUSIC C) does not present a source conflict. However, if the update were to occur, the on-air result would be 3 songs played without an intervening element because 09 JINGLE is intentionally not set with the must-play ('!') flag, and is subject to removal. But, because the user has set UDS2_UPDATE_81 to "M:1", the update does not occur. Why? The performance of this update would not have led to the dropping of any music. Only the non-music JINGLE event would have been eligible for removal. The net result is that, although the update was evaluated twice, it was deemed inappropriate: initially because of back-to-back conflict and then because the zero count of music eligible for dropping was *below* the value set by the user. - Note that the optional value of "at least one non-music" event was set. The presence of the ":05 JINGLE" meets this threshold value. b). Src Event Status ---- ------- ------ !09 :60 SPOT AIRING !09 :05 JINGLE NEXT TO AIR 01 MUSIC A NEXT TO FOLLOW (LOADED) 02 MUSIC B --- 09 JINGLE --- 81 UPDATE AT 10:00 --- 01 MUSIC C --- At 10:00 past the hour, while the 60-second spot is airing with, say, 45 seconds remaining, the initial evaluation reveals that the update can occur. There is sufficient reload time to put away MUSIC A and replace it with MUSIC C. In this case, there are two music events to be removed, MUSIC A and MUSIC B. This music removal count exceeds the minimum of 1 set by the user via UDS2_UPDATE_81=M:1. As a result, the SPOT is followed by a must-play ('!') jingle into MUSIC C. - As a contrived example, presume that the user has set UDS2_UPDATE_81 to the following (perhaps unrealistic) value: "M:4,1". Then consider the following scenarios: a). Src Event Status --- ----- ------ 01 MUSIC A ON AIR 02 MUSIC B NEXT TO AIR (LOADED) 01 MUSIC C NEXT TO FOLLOW 81 UPDATE AT 10:00 02 MUSIC D --- At 10:00 past the hour, while MUSIC A is airing, the update performs...removing all events up to MUSIC D. There's no back-to-back conflict between 01 (MUSIC A) and 02 (MUSIC D). There were two events removed (MUSIC B and MUSIC C). Why did this happen, since a minimum music removal value of 4 was set in this example? The optional non-music value was set to 1. Since there were no non-music events to consider, the update was performed. Contrast this behavior with the following: b). Src Event Status --- ----- ------ 01 MUSIC A ON AIR 09 :05 JINGLE NEXT TO AIR (LOADED) 02 MUSIC B NEXT TO FOLLOW (LOADED) 01 MUSIC C 81 UPDATE AT 10:00 02 MUSIC D --- At 10:00 past the hour, while MUSIC A is airing, the update does NOT perform. Although there's no back-to-back conflict between 01 (MUSIC A) and 02 (MUSIC D), there *is* a non-music event wedged in between the next to air event and the update point. The optional non-music value was set to 1. Since there was the required amount (1) of non-music events and an insufficient number of music events (2, with 4 set as the minimum) eligible for removal the update was voided. UDS2_UPDATE_MUSIC D:<1-3600> UNSET - This ENV is valid only when UDS2_UPDATE_81 is set to a valid value. It is used in conjunction with that variable to govern the behavior of the UDS II's time update 81. - The syntax is a literal 'D' (case insensitive) followed by a colon delimiter and then a string of digits from 1 through 3600 inclusive. If it is set to a proper value, message similar to the following is written to both the DIALOG and UDS2BOOT.LOG files: 5:23:31 PM Time update 81: M:1,1 5:23:31 PM Digital Audio >= 180 seconds counted as music - As one can discern from reading about UDS2_UPDATE_81, the update will be performed only when the number of "music" events to be dropped by the time update equals or exceeds the value set by the user. However, the definition of what constitutes "music" has been rather narrow, eg., the event must have been played from a CD player. With UDS2_UPDATE_MUSIC, the user can now specify a value (expressed in seconds) for any Digital Audio element (played from either a DCS or an AV100 unit) that should be counted as a music item. Because there is no way for the UDS II to discern what is a "spot" vs. "music" played from a Digital Audio source (except in the event of a Discrete DCS music item), the duration of the event is currently the most expedient way to "alert" the UDS II to count that event as being music. As a result, during the time update 81 process (presuming that UDS2_UPDATE_81 is set properly), if the UDS II encounters a Digital Audio event with a duration greater than or equal to that specified by UDS2_UPDATE_MUSIC, it will be treated as though it were music. Note that this environmental variable is designed for future extensibility. Currently the letter 'D' represents "Digital Audio". Other letters may be added to signify additional sources that may be counted as music. UDS2_NO_IMPORT_WARN BOOLEAN UNSET - For users not wishing to notified of a schedule ending prior to 11:00 PM (or 23:00), set UDS2_NO_IMPORT_WARN to a value of 1. As explained in the following paragraphs, the default behavior of the UDS II as of version 1.91n is to issue a warning for what is perceived to be a "short schedule". By default, the UDS II now, by default, warns the user if he or she is about to import a schedule that ends prior to the 11:00 PM (or 23:00) hour. Realizing that the majority of UDS II clients are broadcasters using the program in a 24-hour situation, the 11:00 PM hour was carefully chosen as a typically correct ending hour. Because this is a only warning (and not an automatic abort), the user is free to ignore the warning and proceed with the import process. The text of the warning is as follows: "Schedule ends before 11:00PM load it?" ('N') or "Schedule ends before 23:00PM load it?" ('N') If the user explicitly presses 'Y', there's one more prompt just to make certain that a possibly suspect schedule should be loaded: "Load this schedule?" ('Y') This "schedule ends before..." warning does not appear if the schedule is being imported through non-interactive means, eg., a Nexus-load, via system command 97 or if imported via Alt-F10 "load multiple days". However, in ALL cases -- including having UDS2_NO_IMPORT_WARN set, any schedule with an ending hour prior to 11:00 PM (or 23:00), causes the ending hour to be displayed in red rather than the usual black attribute on the cyan F10 import window. This serves to call attention to a possibly suspect schedule and, of course, may be ignored by the user. If this environmental variable is not set (the default), it is logged to the DIALOG file as follows: "8:19:10 PM End of schedule import warning: on" If UDS2_NO_IMPORT_WARN is explicitly set the message is: "8:21:54 PM End of schedule import warning: off" UDS2_PRINTER_DELAY 1-60 0 Seconds - Normally, all of the following conditions must all evaluate to true before the UDS II will transmit characters to the line printer: 1). Printer logging must be enabled via the F8 configuration window. 2). An event *other* than the live studio source must be on the air. 3). The currently airing event must have at least 20 seconds remaining. 4). The intro time of the event must have decremented to 0. - This works for most clients. However, if a client has disabled the intro clock feature, the UDS II perceives that the intro time is at 0 when each event starts (regardless of whether the event has an intro time specified). - The UDS2_PRINTER_DELAY environmental variable can be set to a value of 1 to 60 seconds (inclusive). If so set, transmission to the printer will be delayed until the currently airing event has (at least) aired for that period of time. - In the case of a client NOT using intro times, this value becomes an absolute "safe to print" threshold. If the client IS using intro times, printing will not occur until either the intro time has decremented to 0 or the event has aired for a period of time greater than that set by UDS2_PRINTER_DELAY, whichever comes last. - If this variable is set, a message similar to the following is logged both to DIALOG and UDS2BOOT.LOG: "12:39:51 PM Printer delay: 10 seconds" UDS2_STUDIO_OFF_AT_SEGUE BOOLEAN UNSET - If set to a value of '1' (as is the case with all BOOLEAN-style environmental variables employed by the UDS II), a live studio source is "faded out" on segue to the next event. The normal behavior of the UDS II is to leave the mixer channel for the live studio on until the intro timer expires. This means, in most cases, that the studio remain on through Digital Audio elements...only shutting off when a music event's intro has decremented to 0. Note that since UDS II version 1.71o, one could achieve the same thing by scheduling a live studio event with a dollar-sign '$' as the first character in the "Sponsor/Title" field. This environmental variable essentially causes ALL live studio events to be treated as though they had this dollar-sign notation. - If UDS2_STUDIO_OFF_AT_SEGUE is set, the following message is written to both DIALOG and UDS2BOOT.LOG: "Live studio will fade on segue" UDS2_TRACK_ZERO BOOLEAN UNSET - If set to a value of 1, the UDS II music database modules will permit an entry with a track value of 0. (This ENV becomes effective with version 1.96w). - If this environmental variable is set to 1, a message such as the following appears in the configuration stanza of DIALOG file: "2:41:39 PM Database entries with track 00 OK" As of version 1.93u, the UDS II started trapping for invalid database items. Among the things considered invalid were entries with a track field of "-00", when not involved in a Discrete DCS context. However, there are legitimate needs for clients to occasionally enter music database items with an explicit track "-00". One such need is for clients to have the ability to perform a database lookup on DCS music events. Rather than keeping a sheet of paper with all of the titles and artists keyed to the DCS cart number, the F5 database window permits this kind of lookup to be done. UDS2_NO_MUSIC_CLOSURE BOOLEAN UNSET - The name of the environmental variable is admittedly somewhat misleading. Because of the expediency of the particular application where it was required, it was so named. Note carefully that the sources "embraced" by the environmental variable extend beyond those of music-only items. - Setting the environmental variable, UDS2_NO_MUSIC_CLOSURE to a value of 1 causes the UDS II to "ignore" a "contact closure" (external print screen) if the currently airing event is any of the following source types: CD Player Live Studio Hard Drive Audio This environmental variable really only has application with a UDS II using the SM-05 mixer. Because closures aren't detected on a "per source" basis, an EOM must be returned via the "external print screen" pins on the 8255 chip. As a result, EOMs may be generated by the external device at any time -- even when the external device is not airing. Because this leads to undesired segues at run time, the environmental variable, UDS2_NO_MUSIC_CLOSURE was introduced. Should such an EOM occur when a CD Player, Live Studio or Hard Drive Audio source is airing, a message similar to the following is written to the DIALOG file: "12:07 Ignored contact closure" If and only if this environmental variable is active, the following message is written to both the DIALOG file and UDS2BOOT.LOG as part of the system configuration stanza: "Contact closures during music are ignored" UDS2_AUTO_UPDATE BOOLEAN UNSET - If using a DPMI version of the software, the user may now optionally set the environmental variable, UDS2_AUTO_UPDATE to a value of 1. If thusly set, this causes the UDS II to perform a periodic automatic recalculation of "scheduled at" times for the remainder of the currently airing hour. This recalculation is pretty much the same as the user explicitly hitting the 'U' key in the F4 editor window. The automatic recalculation process occurs each time a new event starts, under the presumption that all of these conditions evaluate to true: 1). The On Air event has been airing for at least 10 seconds. 2). The On Air event has a duration of 30 seconds or greater. 3). The On Air event's "schedule day" matches the wall clock day of the week. 4). The Next To Air event's "scheduled at" hour matches the current hour of the wall clock. a). It is strongly suggested that a user NOT enable this feature if there's no form of disk caching in place. Since the "scheduled at" time updating process is bound by the speed of physical disk I/O, it becomes painfully slow when there's no caching. b). If the environmental variable is properly set, the following message appear in both the DIALOG and UDS2BOOT log's startup stanza: "Automatic "scheduled at" times updating: on" c). This feature is especially worthwhile in the wake of a time update, since the starting times for events are thereafter automatically reconciled. UDS2_AUDIO_MIXERS 1-7 (inclusive) UNSET Number of mixers - If using an A4000 mixer, there might be a need to map sources beyond the range of those controlled by the mixer. For the sake of this discussion, these will be referred to as "virtual sources". Let's presume that a user has a ten-channel A4000 mixer and desires to have contact closure sources on "channels" 11, 12, 13 and 14. Normally, the UDS II will attempt to route these channels through the A4000 mixer. However, since there is only one mixer present in this scenario, the user can set UDS2_AUDIO_MIXER to a value of 1. This means that only those sources within the range of single mixer (channels 1 through 10, inclusive) will be routed to the mixer. Those "virtual sources" (assigned to channels beyond 10) will not be handled by the A4000. If this environmental variable is set to a valid value (1 through 7), the following message is written to both DIALOG and to UDS2BOOT.LOG: Number of audio mixers: where is the number of user-defined A4000 mixers. One benefit is that by setting this environmental variable, the error messages related to an attempt to transmit to a non-existent mixer will no longer appear. Note also that this environmental variable is meaningless in an SM-05 context. That's because an SM-05 based UDS II system always presumes that there is only one mixer present (with a maximum of five mixable sources). Therefore any source assigned to a channel beyond five (in an SM-05 setting) is treated as "virtual source". UDS2_NO_ALARM BOOLEAN UNSET If set to a value of 1, this causes the UDS II to _not_ trigger an alarm on the audio mixer for a condition other than silence sense. As of this writing, the only "software trigger" for such an alarm is when the UDS II detects an emergency on a Sony CDK-3600 CD player. Because users may not want the "side effect" of a relay firing (possibly starting a fill tape) under such a condition, the ability to disable an alarm in the event of CDK-3600 was added. Remember that because a silence sense alarm is "intrinsic" to the audio mixer, the value of this ENV has no bearing on how the audio mixer will react to a "silent" condition. - If this variable is unset, as is the default, the following message is written to DIALOG and to UDS2BOOT.LOG: "CD player emergency conditions will activate alarm" - If this variable is set the message shows: "CD player emergency conditions will not activate alarm" UDS2_AUTO_ROUTE BOOLEAN UNSET The UDS II (version 2.08j or greater) now supports a feature known as "Auto-Route", which causes the UDS II to alternate between the program and audition channels for music events, while the system is operating in Live Control mode. This permits the operator to have complete control over the fades, especially suited for overlapping music events. In order to enable this feature, the environmental variable, UDS2_AUTO_ROUTE must be set to 1. If set as such in the environment, the following message is written to both DIALOG and UDS2BOOT.LOG: "Auto-Route enabled for music events" UDS2_AUTO_ROUTE_FADE 1-30 15 Seconds When in "Auto-Route" mode, all fades on the UDS II audio mixer are deferred until 15 seconds have elapsed after the song ends. (This gives a good bit of latitude in doing a mix crossover in most cases). However, the user can change this fade deferral value by setting UDS2_AUTO_ROUTE_FADE to a value ranging from 10 to 30 (seconds). That range is inclusive so that both 10 and 30 are valid. Whether explicitly set in the environment or using the default, the following message is written to both DIALOG and UDS2BOOT.LOG to show the current setting of this fade rate deferral: "Fade value while in Auto-Route mode: seconds" UDS2_ALT_GREY_PLUS BOOLEAN UNSET Access via PC Anywhere to a UDS II running on a Windows 9x platform will not permit the PrtScr to be processed to segue on demand. This is in spite of setting the DOS window (under which UDS II runs) to accept the PrtScr key as is, rather than letting Windows 9x fetch it first. In order to allow such an "on demand" segue, DMPI versions (and only DPMI versions) of the UDS II now support a new boolean environmental variable: UDS2_ALT_GREY_PLUS If set to a value of 1, the UDS II will issue a segue code of 1 (the equivalent of a PrtScr press) when the keycode corresponding to the press of Alt-Grey-Plus is received. A regular plus key will not segue nor will an Alt-Plus from the main key rows. It must be the "grey" plus key on the numeric keypad. Both DIALOG and UDS2BOOT logging files report the status under the heading of "UDS II DPMI version extended features" as follows: "Alt-Grey Plus segue key disabled" (Default) "Alt-Grey Plus segue key enabled" (With ENV set) Note that neither of above messages appears in a non-DPMI version since this feature is not available in those flavors. UDS2_TIME_UPDATE_OLD_SKDS BOOLEAN UNSET There may be circumstances in which a user wants time update commands (and other time-based system commands, such as relay closures) to operate even when the currently executing schedule is outdated. Setting UDS2_TIME_UPDATE_OLD_SKDS to a value of 1 disables UDS II's default protection of not executing time-based commands when the schedule does not match the current calendar date. In other words, time updates (and other time-based commands) remaining in an "old" schedule will still function and the user may even add such commands to the outdated schedule via the F4 editor. The recommended course of action is to take measure to ensure that a current schedule is running and simply not deal with this environmental variable. However, it was added for the benefit of stations doing timed-based recording or network cutaways that must continue to occur, even when the wrong schedule is airing. If UDS2_TIME_UPDATE_OLD_SKDS is set, the following message is written to the DIALOG and UDS2BOOT.LOGS files (as part of the UDS II DPMI version extended features stanza): "Time updates WILL occur on non-current schedules" The default logging message is: "Time updates will NOT occur on non-current schedules" UDS2_PIN2_EOM UDS2_PIN3_EOM UDS2_PIN4_EOM UDS2_PIN5_EOM 1-30 0 Source number To take advantage of UDS II's enhanced EOM handling, set one of the ENVs to a source number in the range of 1 through 30, inclusive and then wire a dry contact closure across the pin indicated in the name of the ENV and pin 25 on the 25-pin connector available on the UDS II's RS-422 card. For example, if source 11 is a contact closure event (without an audio controller card), one may do the following: SET UDS2_PIN2_EOM=11 Presuming that pins 2 and 25 are properly wired, a closure across those pins will cause segue code 005 (contact closure EOM) to be emitted if the UDS II is in AutoSegue mode and that source is currently airing. (This provides functionality that the canonical use of an EOM across pins 1 and 25 does not provide). Note that there are 4 such EOM closures available, allowing up to 4 external sources to be mapped to the pins. Realize however that the default function associated with each pin is lost in order to take advantage of the enhanced EOM closure support. The default function mappings are: Pin Function --- -------- 2 F2 Manual/AutoSegue toggle 3 Alt-S Live Studio Event toggle 4 Alt-W Weather Window popup toggle 5 "Remote" escape keypress - For each pin mapped to a valid source, a line such as the following is written to the DIALOG and UDS2BOOT.LOG files: "Contact closure pin 2 mapped to source: 5" "Contact closure pin 3 mapped to source: 6" "Contact closure pin 4 mapped to source: 13" "Contact closure pin 5 mapped to source: 14" UDS2_TIME_COMP_LOG BOOLEAN UNSET If running a DPMI-enabled version of the UDS II (version 2.24c or greater), setting this ENV will cause verbose diagnostic information to get written to the DIALOG file each time a time-compare event segues. (Recall that such segues emit segue code 004, as shown in the SEGUE.TXT file). This form of diagnostic information conforms to these representative examples: 2:47:12 PM Time compare segue at: 1 tick(s), elapsed: 0.10 2:47:12 PM Time compare segue at: 0 tick(s), elapsed: 0.00 2:47:12 PM Time compare segue at: 6 tick(s), elapsed: 0.30 2:47:13 PM Time compare segue at: 10 tick(s), elapsed: 0.50 2:47:14 PM Time compare segue at: 19 tick(s), elapsed: 1.00 2:52:14 PM Time compare segue at: 5462 tick(s), elapsed: 300.00 2:55:13 PM Time compare segue at: 2185 tick(s), elapsed: 120.00 The "tick(s)" value is an internal counter maintained by the UDS II which is generated by the underlying hardware, via interrupt 0x1C. The "elapsed" value is the total elapsed time of the event (as calculated by the UDS II) when the segue occurs. If this environmental variable is set to a value of 1, the following is written to both the DIALOG and UDS2BOOT.LOG files as part of the "UDS II DPMI version extended features" stanza: "Time compare verbose logging is enabled" The default message (when the ENV is not set) is as follows: "Time compare verbose logging is NOT enabled" UDS2_EAS_SOURCE 1-30:2-5 UNSET Source/pin The syntax for the value assigned to this environmental variable is: UDS2_EAS_SOURCE=:. The colon is a literal, required character that delimits the two numerics on either side of the delimiter. The value may be any legal UDS II source in the range of 1-30, inclusive. The may be any value in the range of 2-5, inclusive. An event corresponding to the number will be inserted into the schedule (into the "Next to Air" position) upon receipt of a contact closure on the specified. Note that only the first pin is specified in the value of the ENV. The ground (pin 25) is assumed. Thus, the following mappings are available: Pins Function --- -------- 2-25 F2 Manual/AutoSegue toggle 3-25 Alt-S Live Studio Event toggle 4-25 Alt-W Weather Window popup toggle 5-25 "Remote" escape keypress Examples: Setting EAS Source Function Mapping ------- ---------- ---------------- UDS2_EAS_SOURCE=6:4 6 Weather popup toggle UDS2_EAS_SOURCE=8:2 8 Manual/AutoSegue toggle UDS2_EAS_SOURCE=:2 INVALID INVALID UDS2_EAS_SOURCE=7 INVALID INVALID UDS2_EAS_SOURCE=7:11 INVALID INVALID (no such pin) UDS2_EAS_SOURCE=6 : 3 INVALID INVALID (white space) Notes and caveats: 1). The source component specified by UDS2_EAS_SOURCE must exist in the user's equipment file. Furthermore, it must be an source type defined as either a closure type or live studio. This prohibits the use of a CD jukebox or a digital audio source. The insertion of such sources are reliant upon having an event ID associated with them which the EAS insertion feature does not provide. 2). If the source is invalid (as explained in 1), above), the processing of the contact closure will fall through to attempting to process the corresponding UDS2_PINx_EOM, if it exists. Otherwise, the default behavior of the pin mapping prevails. Thus, the "pin priority" is as follows: UDS2_EAS_SOURCE UDS2_PINx_EOM default mapping 3). The parser is very strict (as shown the example above), with whitespace not permitted. The value string must conform to the following extended regexp: "^[1-9][0-9]?:[2-5]$" Thereafter, the values are ranged checked. Then, they are checked for conformance to the equipment file (as explained in 1), above). 4). The logging files (DIALOG and UDS2BOOT.LOG) provide the following information in the "UDS II DPMI version extended features" stanza, as shown by the examples below: - If the pin and source are valid: "Contact closure pin 4 mapped to EAS insertion source: 6" - If the pin is within range but the source is invalid: "Contact closure pin 4 NOT mapped to invalid EAS source: 3" - If the user-supplied value is malformed, nothing is written to the logging files regarding EAS insertion. ==================================================================== VII. Here is a summary of diagnostic dribble file-related ENVs. Note that some of the strings are intentionally repeated from other sections. ------------------------------------------------------------ ENV NAME VALUE Default Units ------------------------------------------------------------ > NOTE: As of v1.80cà, the creation of ALL dribble files is supported *only* with the protected (DPMI) version of the software. In all other versions, the setting of any of the following environmental variables does nothing whatsoever. AV100_DEBUG BOOLEAN UNSET - Forces an EXTREMELY verbose diagnostic dribble file (AV_BUG.DRB) to be written to the CWD. WARNING: this dribble file can easily consume a typical Z-4000 computer's hard drive space in a matter of 2 days of dribbling. It should only be enabled per the instructions of On Air USA and the file should be unlinked as soon as possible. DCS_DEBUG: - Enables a diagnostic dribble file (DCS_BUG.DRB) to be written to the CWD, showing the state of all DCS-related variables when each message is transmitted and received from the DCS via the RS-232 port. This produces a reasonably large file but it is not nearly as huge as the AV_BUG.DRB diagnostic dribble file. SKD_DEBUG BOOLEAN UNSET - Upon each segue, the entire contents of the internal SkdAry array of schedule records is written to the CWD in the file SKD_BUG.DRB. This can produce a VERY large file. In addition, the current "first free" file handle is logged to the file. This permits On Air USA to diagnose those conditions related to error 9901, known as "file handle creep" caused by a routine opening a file but failing to close it. UDS2_DBASE_VERBOSE BOOLEAN UNSET - This environmental variable is available only with the DPMI (protected mode) version of the software. This can produce a VERY large file in the UDS2 directory! The file will become especially big if automatic music runtime correction is enabled because every instance of a song that airs will get a change written to the file. As a result, it is strongly advised that users not set this ENV unless explicitly directed to do so by On Air USA. If set, every transaction involving the UDS II music database is logged to this file. Not limited to only those changes, additions or deletions made via F5, any agency capable of modifying the music database will have such modification reported in the file "UDSMUSIC.LOG" in the current working directory. ----------- These are emacs words for the ispell utility -------------------- LocalWords: RSHD SKDS PLAYOUTDATE PINGPONG CMCR Src PADCHAR NUM SKD SkdAry LocalWords: VAL XmitChar DENONDRB BPS emptor quiescence