The Property Editor is probably the place a user spends most of his time. As soon as an operator cues a template, Director creates a template instance of that template. Think of the template as a blueprint and the instance as version of that blueprint where all the values have been filled out. If an operator cues the same template multiple times but with different values, each cueing creates an instance and the original template as defined in the Ventuz scene is never changed.
The Property Editor changes its appearance to match data values of the cued template instance. The following image shows the Property Editor in three different states. In the left version, no template is cued and therefore the Property Editor is empty. Once a template is cued, a header and footer become visible as well as the data fields for the template.
The header contains status information about the current template instance:
The actual content of a template instance of course uses most of the space in the Property Editor. Which controls will be shown depends on the data fields the designer of the template has exposed to the end-user. A string will result in a text box, a numeric value in a numeric up down control or a slider, an image in a placeholder box and so on. The Property Editor dynamically generates a user interface that looks as if the designer of the template would have programmed it specifically for that template.
Let's take a closer look at the content of the template instance shown in the middle of the screenshot above:
The label "InGame Graphics" as well as "01NS1L" represent templates. Ventuz Director uses a highly flexible system of templates and sub-templates. Templates can have slots for optional additions that can be added and removed from it's parent template. For example, imagine a scoreboard that has an optional sponsor area that moves out of the scoreboard and sticks to its side. The scoreboard would be one template and the sponsor area a sub-template for that template. It is up to the operator to extend the original template with the sub-template or not!
Such an extension slot is represented by a light gray box. In the example, the box at the bottom of the content visualizes that a sub-template of the type "UpperThird" can be inserted here. This can be done by clicking on the box and a selection of fitting templates will be presented. The inverse operation is also simple: To remove a sub-template, click on the cross to the right of the template name. In the example, both the "InGame Graphics" and "01NS1L" template can be removed.
As stated before, Assets are represented by placeholder boxes. In the example above, both "Main visual" and "Addon visual" can each hold an image. Either drag and drop an image from the Visual Browser or click on the empty box to again open a selection of fitting images.
If any data fields are changed, a red bar will appear to the left of the respective field. This visualizes the value is different from the original. Those changes can be saved or reverted using the respective buttons in the footer.
Inside the Property Editor, triggable events on a template are represented as buttons. While something is cued, that event will only be performed on the cued data and therefore not visible on screen! To trigger an event on-air, switch to the On-Air Editing Mode.
Finally, the footer contains actions, all of which will be discussed in later chapters since they relate to Storing and Re-using Content. Again, from left to right:
Any parts of the Property Editor that have not been mentioned in this chapter are not relevant for the basic workflow of cueing/taking a template and will be explained later in the chapter on Content References.