In this Tips and Tricks, we’re going to look over the Triggers view to cover the generic properties that all Triggers share.
Firstly, select or create a new Trigger, as shown below.
Each trigger is assigned the next available Number for reference as it is created. Trigger numbering is not essential, as the controllers manage triggers based on the order they appear in the list. However, for tidiness and on larger, more complex projects, programmers may choose to use the numbering functionality to manage and organise triggers into types, for example, such as using 101-199 as Timeline triggers, 201-299 as Scene triggers, etc.
A new feature we have recently added is the ability to easily renumber triggers. This can be done by making a selection of Triggers, right-clicking and selecting Renumber triggers…. Then, enter in the new number that you want to start from. Designer will then automatically increment each selected Trigger’s number by 1 after that.
Clicking Yes or No will enact the number change, with clicking Yes causing all Enqueue Trigger actions (not including ones enacted via script) that link to the selected Triggers to automatically update to the new number.
Name and Description may be fairly apparent when in the trigger window, but triggers are displayed in various locations including Simulate project mode, Web interface control, Director override and Cloud triggers. If left unnamed, only the trigger type will be listed. The Name should be meaningful to any remote user who may need to activate triggers from those locations. The Description only appears in the triggers window and trigger reports, allowing the programmer a ‘notes’ field for additional detail. So, a Digital Input trigger could have a name such as “RideCar ZoneB” and a technical description such as “IR beam #4”.
Group is a great visual aid, highlighting your choice of triggers by giving them different colours on the Trigger view. Once a group is set, we will colour in the number column, allowing for easy recognition. This can be used in combination with the numbering organisation stated above to allow for quicker navigation of the Trigger view. The Filter button on the toolbar allows you to then filter the Trigger view so you can display and manage just your trigger subsets.
Now, we have 3 checkboxes. These are Absorbed, Included and Enabled. By default, they are all typically checked as that represents anticipated basic, standard behaviour.
The order of triggers in the Trigger list matters. When an event is received by the controller it runs down the trigger list in order from the top. When it finds a trigger (or trigger and condition) that matches it, the controller activates the action and the trigger search is “Absorbed” – in other words, it stops looking down the list for further matching triggers.
There may be circumstances that you have further triggers that you also want the system to find. In this event you would set the higher trigger to not Absorb, allowing the further events to be found. But bear in mind that we support multiple actions on a single trigger which is normally the best way to achieve multiple events from a single input.
Please note: best practice is to make sure most triggers are set to absorb unless specifically required not to, so that the controller is not endlessly searching through the trigger list which could cause performance issues.
Included allows the programmer to select which triggers the users may see in remote access locations. By default, with this checked, the Web Interface Control tab, Cloud interface and Director Override page display every trigger in the list. Many triggers may be confusing, irrelevant, or inappropriate to have a user randomly activate, so can be made unavailable by unchecking here.
The Enabled checkbox allows the user to remove a trigger’s functionality from the project without deleting it. It remains in the Designer file so can easily be enabled again, rather than needing to recreate it. This is useful for testing; if you want to experiment without a Trigger, or you have a debug Trigger used for testing, or you are trying a variety of different ways to achieve something.
There are additional Trigger properties that can be altered, but we hide these by default as they are more advanced. These can be enabled easily by clicking … at the top of the Trigger properties panel, then Enable Trigger Controller Edit
This will add two new options, Controller and Test conditions on.
Controller determines which controller the Trigger will run on. For example, setting a Startup Trigger to Controller 1 will mean that the Trigger only fires on Controller 1, and will not fire on the other controllers in the project when they start up. This is useful if you want different controllers to do different things when they boot up, such as one controller to decrease its intensity, but not the others.
Test conditions on will force only one controller to test its conditions. For example, if we have a Startup trigger with a Condition determining if input 1 is high or low, but we only want to test that on Controller 1 but apply to all controllers, then setting that here will allow all controllers to react appropriately, rather than check if their input is set to high or low, as it would with the dropdown set to Local.
It may be worth noting that Triggers can also be changed together. If you select multiple Triggers, all settings, bar number, can be changed if they have the same options. This applies to all Triggers types, so multiple Timeline Started and Timeline Ended Triggers can have their Timeline field altered simultaneously.
There are quick tips video tutorials illustrating both Absorb and multi-trigger adjust which can be found here.
