This page gives you an overview of the different ways to control Ventuz - feeding in data, changing scenes, using the template based workflow, getting information about a Ventuz machine, configuring a Ventuz Runtime and so on - quickly you can find yourself in a situation where it is hard to decide which kind of Remoting you need to use or even where to get the information for this decision. The same is the case for customizing or extending Ventuz' functionality. This section is created to help you with this type of problem.
To use Ventuz in a production environment it is often necessary to control it from outside rather than having it as a stand-alone solution. Ventuz' open architecture enables users to embed Ventuz in multi-media environments. Depending on the embedding system, Ventuz offers different kinds of communication that can help you to easily create solutions for your complex setups.
The next sections will provide you with a list of cases in which you need to control Ventuz.
Oftentimes a setup requires a kind of communication between two machines or more. Depending on what kind of communication you need and what kinds of systems need to communicate with Ventuz.
To communicate between several Ventuz instances you can use the Osc Nodes. Most commonly you will want to trigger methods on keyframe animations. Sometimes you want to send values from a User Control Interface to another Ventuz Machine. E.g. for a control touch table in front of a videowall. If you need to load/unload Scenes or want to use templates consider using designated Scene Ports or Template Ports in your Layout Scene.
If any of the involved Ventuz Instances runs on a Machine Cluster you can synchronize incoming events and values using the Cluster Nodes.
Since Ventuz runs on a Windows-based environment it might be useful to also run a Windows environment. If this is the case already or you can plan to do so, you have many different options to choose from.
Firing events and changing data in already loaded Scenes:
Loading Scenes and changing their state in simple setups:
Loading Scenes, changing their state in complex setups, using a Template-based workflow:
To communicate back from a Ventuz Runtime machine to the Windows Machine you again have some other options:
You can also control Ventuz from mobile phones using OSC Nodes or the Deprecated OSC Remoting. If you need scene loading, again you can consider using the Remoting4 HTTP API for this - maybe even with a responsive UI that can also be accessed from laptops or other machines.
If you have any other machine that needs to control Ventuz you need to consider which protocols are fairly easy to implement on its environment. Likewise consider what exactly you want to achieve and decide for the API that you feel most comfortable with for this use-case. Oftentimes you can use the Remoting4 HTTP API, CLI Remtoing or you might need to implement the underlying Remoting4 OSC API.
To communicate with a server anywhere - not only in cloud-based environments - you can create an HTTP API and access it e.g. with the Simple HTTP Node. If you use a third party HTTP API you might also have a .NET library from it and can use the Script Node to implement it.
To communicate with a Ventuz Director machine you will need to implement the HTTP Director Remoting API.
Sometimes in order to integrate Ventuz in your environment you will need to add new functionality to it that is not included natively. Depending on the type of new feature you have different options for this:
Use the [VentuzExtensionsAPI Ventuz Extensions] to write your own nodes.
You also have some options to integrate third party hardware - how to do that is a rather straight forward decision, compared to what Remoting API to use. Most of the times the manufacturers offer some kind of streamlined way to do that, e.g. a programming library.
If the hardware supports generic protocols, that also Ventuz can handle this might be an easy way. Examples for this are DMX, OSC or TUIO. Have a look at the IO Nodes to get an overview of other supported protocols.
If the hardware does not support such generic protocols, that are also handled in Ventuz you will need to integrate a code library with the Script Node. Best case is when you have a managed .NET DLL, but you can also wrap an unmanaged C++ or C DLL as well.
Currently we support GPIO Devices in Director natively. For other hardware you will either need to use a Director Plugin or a middleware that controls the Director via its Remoting API.
This page can give you an overview of the available options when it comes to remoting or customizing Ventuz. While this is helpful in deciding which protocols or APIs to use you will need to learn more about them on the respective pages, linked in the lists. Also it might be a good idea to have a look at the Programming Quick Guide to get an overall overview of how to extend Ventuz generally.