Version 1.7.1.04 Changes
Last updated
Last updated
Note: The changes in this version of software are both ongoing and to be considered beta. It is recommended that you take a backup before moving to this version of software and monitor existing timer events closely after the initial update to make sure they are all working correctly. Report any issues to support if you encounter any.
This version adds several additional properties to DateTime and DayOfWeek timers. These timers can now represent a time range rather than just a specific time. As such there is now a start and end time property. Additionally, it is now possible to specify a property or route change to take place at the start and end times of the event without requiring a logic flow.
The timers list now contains a number of additional fields including DerivedStartTime, DerivedEndTime, and ElapsedEnd. It also has a Cleanup Options link which can be used to determine when expired timers will get deleted from the system as described below.
Since DateTime and DayOfWeek timers now have both a start and an end time, these are expressed in the list by the DerivedStartTime and DerivedEndTime columns. In the case of DateTime timers, these will carry the start and end times of the events. In the case of DayOfWeek timers these times will move to the next start and end time once a specific day’s iteration of the event completes. The NextRaiseTime may be the next start time or the next end time depending on whether the event is still upcoming or is in the range between start and finish. The elapsed column is now titled ElapsedStart and represents whether the start of the event has elapsed whereas the ElapsedEnd represents whether the end of the event has elapsed.
Additionally, Core Pro timers now have a cleanup option accessible by clicking on the “Cleanup Option” link at the top of the timers list:
By default, the value will be -1 which means DateTime timers which have completed their execution will not be deleted from the system. Setting a number of days into this dialog and applying that number will cause single execution datetime events to be deleted from the system after the requested number of days has passed after the timer has completed executing. A value of 0 will cause the timer to be deleted sometime within the hour or two after the timer has completed execution.
When creating or editing a date time, additional properties will be present in the configuration editor:
There is now both a start and an end time so that a time range may be expressed. If the end time is not defined or is less than the start time, it will be ignored and will not execute. Within logic flows in addition to the elapsed time which will be set true when the start time executes, there is also an ElapsedEnd property which will be tripped to true when the end time of the time range is reached.
Additionally, 4 fields have been added for setting a route change or property change that should take place at the beginning and end of the event time range. If left blank, the event Elapsed, and ElapsedEnd properties can still be used in logic flows like previous versions of the software. However, you can add a change directly to the timer by clicking on the ellipsis button and selecting the correct parameters for what should happen at the start and/or end of the time range. The dialog that is presented closely follows the dialog for scene item selection. For example, clicking the Start Property ellipsis button will present the following dialog:
Selecting a router from the Import From list will present the router’s destinations. Selecting a destination and clicking import will then make that destination be selected in the Start Property field.
Selecting the endpoint button instead will bring up the standard logic flow end point dialog where any property in the system may be selected as the change point.
The Ios button will return you to the io selection list. Selecting either a destination or an endpoint will fill in the start property field.
Ordinarily the Start Value field will also get filled in with the current value of the Destination or property selected. Using the ellipsis button next to the start value field will allow you to select a different source or property value and the dialog will present different options accordingly.
This process can be repeated for the end property. For example, if you want to route a studio to an air chain at 4:09 PM and then back to an automation system at 5:09 PM on a specific day, the DateTime event might look like:
Once stored the actions will be executed at the start and end times of the time range.
The “Switch Fields To Advanced” link will change the values presented in the property and value fields to their actual values rather than the friendly display and make them editable for advanced users:
When creating a recurring timer (usually called a Day Of Week Timer), the changes to the editor are almost identical to what was described above for the one time date/time timer. An EndTime set of fields have been added and the same start and end property and value fields have been added to the DayOfWeek timer editor:
With a recurring timer, on the weekday that is selected for the timer to execute, the start time and end time values will be used to fill the derived start and end time properties for the day. At the correct start time on the day, the Elapsed property will be set to true and any configured start property change executed. And at the end time, the ElapasedEnd property will be set true, and the end property change will be executed if one is configured. The Elapsed and ElapsedEnd values will be reset to their false state sometime in the 2 hours leading up to midnight and/or early on the next day.
It is important to note that Elapsed and ElpasedEnd properties can also be used in logic flows for both DateTime and DayOfWeek events regardless of whether a change is configured in the event itself. However, changes configured in the event directly do not count against the logic licensing of the system.
Previous versions of the software would use the browser’s UTC offset when creating a new clock based DateTime or DayOfWeek timer. This also caused odd display issues when editing events from a Core PRO in one timezone while using a browser in another. This version will always display the offset and specific time as it is set in Core PRO. Additionally, new events will be created using the offset defined in Core PRO by its current time zone rather than the browser’s offset.
