Designing Monitoring Scripts

When users require even lower level control of the system, manually writing Lua scripts becomes essential. Most problems can be expressed as a number of loops containing conditional tests, and acting based on the state of components. We refer to these as Just Macro Monitoring Scripts, and many examples are available to download in the downloads section. When we implement these scripts they always follow the same process.

Start by creating 2 new scripts, one called MY_MONITORING_PROCESS and one called MY_MONITORING_STOP. Obviously change the prefix on the name to something meaningful and related to what you are monitoring. In the example shown we are going to switch an XKeys RED backlamp on when our HyperDeck is recording, and switch it off when the Hyperdeck is not recording.

So to understand how to do this we must introduce a concept in JustMacros called The Environment. Each script in JustMacros runs within its own Lua virtual machine and thread. This allows multiple scripts to be executing simultaneously. However it has a drawback. Scripts cannot interact with each other, each script is effectively running a separate program that gets launched when you EXECUTE it, and terminates when it has no more commands to run. This means if you establish variables within a script, when the script ends, the variables are destroyed and are no longer accessible.

The JustMacros Environment helps solve this problem. The JustMacros environment is a Key/Value store that persists always. It is cached to the Windows registry and internal file on Mac, however it is primarily held in main memory (only being stored to disc no more often than 2 seconds). Each Environment Key/Value pair is protected by a critical section, this is a mechanism that prevents the system crashing when two scripts try to read/write the same environment variable at the same time, but users can simply assume they can use EnviroRead ( Variable-Name ) and EnviroWrite ( Variable-Name, Variable-Value ), from any script and be assured the values will remain between different scripts even after restarts and reboots.
We now have a mechanism whereby we can start a script, and put it in a never ending loop waiting for another script to terminate it, we can write a monitoring script that looks like this

The monitoring script is currently doing nothing, except if the environment variable is already set TRUE, it sets it to FALSE, and then waits an appropriate amount of time for any existing monitoring process to terminate. This means users can edit the monitoring script whilst it is running, by hitting EXECUTE after making changes the existing process will terminate, and the new modified one will start. The Stop script that looks like this:

All that is now required is to add the conditional that checks to see if the Hyperdeck is recording and sets the XKeys button. This code looks like:

We have introduced two more variables XKEYS_PANEL_INDEX and XKEYS_BUTTON_NUMBER. Which is added at the top of the script where we originally were just defining the HYPERDECK_NUMBER to be one.

We must convert from the Unique ID we have given our XKeys Panel, and the index that panel is currently enumerated at. Because this is a common process, VIS Visual Information Systems provides a number of samples utility script libraries. One of these is called XKeysTools, and it contains a function called XKeysPanelIDToIndex. In order to access functions in other scripts, the other scripts need to be loaded into memory when the processing script runs, basically compiled into the Lua Virtual machine that is running the script. This is done using a JustMacros $$USES technique.
Put simply, when JustMacros runs a script, it first reads through the script looking for comment lines containing:

$$USES “ScriptName”, “AnotherScriptName”

Although Lua itself has a mechanism for including scripts in other scripts, that involves accessing the hard drive. JustMacros loads all scripts into memory at start up, and hence when including scripts using the $$USES technique, there is no need to access the disc. Essential when running millions of scripts per day. So the completed monitoring script, with all required parts now looks like this:

As many monitoring scripts as you like can be running in the background. It is important to have a Sleep(XX) in the script, otherwise the loop will run many thousands of times per second, and be very wasteful of CPU resource. It is expected that users will actually have just a few monitoring scripts, that will monitor groups of related properties and functions.


We should also now introduce one other type of XKeys Button type. The STANDARD type XKeys Button. This is one of the options when EDITING an XKeys button as discussed in the First XKeys Panel section of the website. However a STANDARD button has no default behaviour whatsoever, it simply exposes the Button Pressed and Button Released events, and allows users to allocate Lua code (rather than a prepared Script file) to buttons.

Our Hyperdeck Record button indicator light, really needs to be able to start and stop recording, and a STANDARD button type makes this a very easy task.

So we now have a Button on an XKeys panel that will start and stop the HyperDeck Recording, and illuminate when it is recording, in response to the Hyperdeck, not whether or not JustMacros has asked it to record. This means you can start and stop recording from the front panel on the Hyperdeck, or from the XKeys Panel, or another script, and the XKeys back-lamp will show correctly, because it is not only being updated when the button is pressed, but whenever anything changes on the hyperdeck by the Monitoring Script.