The Machine Configuration is a project independent file that handles and configures all settings related to the Ventuz system. Most of the settings are hardware related but it also contains network and identification settings.
This configuration affects settings of your local Ventuz installation and probably is needed to be changed if the system is used for another project.
The Machine Configuration is stored in a binary file located at
C:\ProgramData\Ventuz\MachineConfig3
The folder ProgramData is a hidden system folder. The Windows Explorer View option Show hidden files and folders has to be enabled!
This general information about the Ventuz Machine can be used in several ways. A scene could change dynamically depending on the ID values (see System Id Node) or remote/control programs use this data for identification. A Ventuz machine can broadcast this information across the network to notify other system about its presence. See Machine Signature.
| Name | Name of the Ventuz machine as a human readable text. Avoid using special characters (non-ASCII). |
| Group ID | Group ID this machine belongs to. A value of 0 means no group at all. |
| ID | The machine ID within a group. Can be zero, but it is recommended to use a value higher than 0 to indicate a valid ID. |
| Multicast MachineID | If enabled, the Machine Signature of this machine is broadcasted across the network. |
| Timecode Display Format | In Ventuz, time is always handled as a fraction of seconds, but timecodes can be displayed in any desired format. This is just a display feature and does not affect any functionality. |
| Timecode External Source | Not supported yet |
| Enable Cluster Clock | Enable this option to send and receive timing information via network. Ventuz machines in a Cluster share and synchronize their clocks if they all belong to the same Group ID. A Group ID of zero is not valid. |
The Ventuz Input Subsystem is capable of distributing input information from one machine to a cluster of machines. For example, a mouse attached to the host computer can be relayed to a number of rendering client machines. For more information, see Input Handling inside Ventuz.
| Single Machine Setup | The machine will only react on input information from devices attached to itself. The information will neither be broadcast to the network nor will the machine react on any information that may be broadcast by a Master machine in the same network. |
| Master | The machine will broadcast information received from hardware devices attached to itself into the network. It will not react to the information directly but listen to the sent network packages in the same way as a Client machine. |
| Client | The Ventuz scene will not receive any input from hardware devices attached to the local machine. It however will receive and react to input broadcast by the Master machine. |
| Processing Delay | When using multiple machines, each may have a slightly different latency when it comes to receiving information from the input Master. A machine caches received information until the machine's clock matches the timestamp in the input information package plus the processing delay. So if it takes up to 3 frames to send information from the host to one machine but only 1 frame to get it to another, a sufficiently high processing delay forces all machines to process the information at the same time. |
| Scaling Factor | Use this value to scale the Inertia and Tick Attraction Threshold of all Translation/Rotation/Transformation Nodes. This is most useful when the target presentation system has a much larger display (in physical size, not resolution) than the system the scene was authored on but the node behaviors should feel the same. |
| Scale with Window Size | Both the Inertia and Tick Attraction threshold are based on the nodes mapping area, not pixel resolution. Therefore increasing the window size will increase the size of the mapping area coordinate system in screen space and a specific movement will result in a smaller velocity than before. By activating this option, Ventuz will compensate for such changes automatically. |
The TUIO network protocol is often used by camera-based tracking systems or other dedicated Multi Touch input devices. It is the de-facto standard for transmitting touch information between devices/machines. Touch LCD displays, however, often only implement the Windows Touch protocol.
| Enabled | Enables the TUIO input. |
| UDP Port | UDP/IP port for TUIO messages. The default port used for the TUIO protocol is 3333. |
| Multicast IP | Multicast IP address used for TUIO messages. If left empty UDP Unicast is used and the TUIO sender must send the data to the local IP address of this Ventuz machine. |
The Windows Touch API was introduced by Microsoft with Windows Vista/Windows 7 to present a uniform way of devices interacting with the Windows operating system. It is usually only used by the simplest of setups: a single touch LCD display that is connected to a single machine. To support multi touch interaction with Windows applications that have no explicit multi touch support, a Windows Touch display generates both touch as well as artificial mouse information.
| Enabled | Enables the Windows Multitouch messages and blocks the artificial mouse messages generated by the same display. To use a touch display with mouse I/O nodes, deactivate this checkbox. |
| Enabled | Enables the .net Remoting remote interface. |
| TCP Port | TCP/IP Port to be used. |
| Enabled | Enables the CLI remote interface. |
| Command Separator | Line-ending to be used for CLI commands. |
| Line Separator | If text values are transferred, this line-ending is used to substitute line-feeds. A safer way to transfer line feeds is to HTML-encode them, e.g. |
| Command Indexing | If Command Indexing is enabled (other than None) every command has to be led by an command index value. Any response to this command will be send with same index number. The mode Advanced allows to send an index of -1 to tell the CLI that no response is required at all. |
| Encoding | Selects the character encoding to be used. |
| Enabled | Enables the OSC remote interface. |
| Receive UDP Port | Defines the UDP/IP port to use for receiving OSC messages. |
| Receive Multicast IP | If specified, the OSC Remoting listens to a UDP Multicast group. If left blank, UDP Unicast is used. |
| Send Enabled | If enabled, externalized events are sent as an OSC message. |
| Send UDP Port | Defines the UDP/IP port to be used for sending events. |
| Send Multicast IP | Defines the UDP/IP address to be used for sending events. |
| Enabled | Enables the Miranda/Vertigo remote interface. |
| TCP Port | TCP/IP Port to be used. |
All hardware devices listed here (except Video Out) are handled as a list of Device Descriptors. This list can contain an unlimited number of Device Descriptors where multiple instances are allowed. The Ventuz Nodes never access the hardware directly. They always store the list index of the device inside the Machine Configuration. This technique makes it possible to re-configure a Ventuz Project to run on a new or different system without the need to modify the Project/Scene itself. All that is required is to adjust the device lists inside the Machine Configuration.
All device-lists are edited the same way. Device Descriptors can be added, edited, moved or deleted. Each Device Descriptor is of certain type. One of these types is System Enumerated. The Windows operating system is able to enumerate devices to applications like Ventuz. Applications can query the lists and access a device by its list index. This is exactly what happens if System Enumerated has been chosen for a Device Descriptor: It just stores the index of the list that Windows has reported.
The default Device Descriptors in a list always use the System Enumerated types to ensure that 1st Video In always addresses the first available video input hardware.
Unfortunately, it can happen that the order of the devices that are reported by Windows, changes if any other hardware configuration is changed! The system enumerated Device Descriptors can be reordered in such a case! To avoid this, the type Local Hardware is offered on some device types. This type stores the Windows Device ID, which does not change.
If Local Hardware is selected, an optional hardware related configuration might be possible. Such configurations can only be stored if the type of the local hardware is known to Ventuz. System enumerated hardware cannot store a configuration.
This page does not follow the standard device configuration pages. It is only available in the Ventuz Broadcast Edition. See Broadcast Video Output.