How to use Silverstack’s scripting feature

Silverstack already covers a broad range of on-set data management and dailies workflows out of the box. From reliable offloads to advanced dailies creation, Silverstack XT and Silverstack Lab are built to handle the demands of most productions. But in reality, no two workflows are ever quite the same: pipelines evolve, requirements shift, and edge cases are the rule rather than the exception.

That’s why we’ve taken things a step further. With the introduction of scripting, Silverstack now gives you the flexibility to extend and adapt workflows with your own custom logic. Whether you want to automate repetitive tasks or enforce production-specific conventions, scripting opens up an additional level of control that seamlessly integrates with Silverstack’s workflow concept.

In this article, we’ll explore the new scripting feature through two practical use cases. These examples should be seen as a starting point for your own exploration, since scripting can be applied in many different ways. You can decide how and when it fits into your workflow, depending on your specific needs. It is simply another option in Silverstack’s toolkit, alongside presets, templates, and configurations, all designed to help you shape Silverstack to match the way you work. Let’s take a look! 

Scripting in Silverstack: What’s new?

Silverstack now includes a Lua API for accessing some of the data inside Silverstack, and a built-in script editor. Lua is a lightweight, self-contained scripting language designed for embedding into applications. Its small footprint and simple core make it well-suited for implementing extensible scripting features, while Silverstack defines the available functionality and environment. When opening scripts from the workflow configuration window, you can access the workflow context to gain relevant information for your scripts, such as clip metadata and more. Your added scripts will then run as part of your configured workflow. We will look at the script editor in more detail further below, but first, let’s clarify how scripts work conceptually. At a high level, scripting lets you extend workflows in two ways: during ingest or as a post-step after a job has finished. Let’s quickly look at both cases.

a) Metadata adjustment scripts: 

These run during ingest and let you automatically adjust or enrich clip metadata. A typical request DITs get from post-production is to gather consistent, exhaustive metadata across different camera models. So these scripts could be used to clean up metadata, such as removing leading zeros from take numbers. You can recognize these scripts by the functions onStampVideo and onStampAudio: 

1 function onStampVideo(videoClip)
2  local take = videoClip:metadata():getTake()
3  local n = tonumber(take)
4  if n then videoClip:metadata():setTake(tostring(n)) end
5 end

b) Post-step scripts: 

These scripts are added as post-steps to a job and automatically respond to workflow events like a completed backup or a transcode. The script below, for example, would write a small log file to the job’s working directory. As you can see here, those scripts can trigger actions outside Silverstack. All post-step scripts run using the onFinish function: 

1 function onFinish(_, _, workingPath)
2  local logFile = workingPath .. "/Silverstack_Log.txt"
3  os.execute('echo "Silverstack Job Finished" >> "' .. logFile .. '"')
4 end

The great thing about scripting in Silverstack is how flexible these two approaches are, allowing you to apply them in a wide range of scenarios. Before we continue diving into a few more concrete examples, here’s a quick heads-up.

A quick heads-up: this is not a coding tutorial

Please note that this article is not about teaching you how to code – and it doesn’t have to be. You don’t need to be a software developer to benefit from the new scripting feature. If you have a basic understanding of the underlying concepts or if you’re comfortable adapting existing examples, you can already put scripts to good use in your daily work.

Besides that, nowadays, it’s easier than ever to learn coding with the help of Large Language Models (LLM) that can provide you guidance with writing your first Lua scripts. 

That said, the main goal of this article is to explain why scripting can be useful and what kind of problems it can help you solve. Further details and step-by-step instructions can be found in the Knowledge Base, while an in-depth scripting documentation is available on GitHub.

Two real-world examples

Without further ado, let’s look closer at two common scenarios where custom scripts can make a real difference in your day-to-day work.

Example 1: Automatically adjust metadata during ingest

Metadata is a constant companion on set. Some values come directly from the camera; others need to be added, changed, or normalized during ingest. Doing this manually for every card or clip can be repetitive and error-prone: small inconsistencies easily slip in.

With metadata adjustment scripts running during the ingest step, these adjustments can happen automatically. A script can check whether a certain metadata field is already set and only fill it in if it’s missing or different from what’s required. This keeps existing information intact while ensuring that important fields are always populated. This is especially important when working in multi-camera setups where metadata can differ between manufacturers or even cameras.

For example, you’re shooting with an ARRI ALEXA 35 alongside an ARRI ALEXA Mini LF as your second camera. When ingesting the footage, Silverstack extracts the first camera’s letter as “A_” while the second camera’s letter is simply “B”. A script can help you adjust the camera letters to the desired pattern. To achieve this, the ingest script could look like this:

1 function onStampVideo(videoClip)
2  local cameraIndex = videoClip:metadata():getCameraIndex()
3  if cameraIndex == nil then return end
4  local newCameraIndex = string.gsub(cameraIndex, "_+$", "")
5  videoClip:metadata():setCameraIndex(newCameraIndex)
6 end

For now, don’t bother too much if you don’t fully understand the syntactic details of the script yet. In line 2, the clip’s current camera letter is extracted, and in line 3, the script will stop if the clip does not contain any camera letter. Line 4 replaces any underscore character in the camera letter with an empty string and stores it in the variable newCameraIndex, which is then set as the clip’s new camera letter in line 5. It’s as easy as that!

Instead of modifying workflows or relying on manual checks, the logic can be encapsulated in a small, focused script that runs during ingest. The ingest workflow itself remains unchanged, and the additional logic operates within clearly defined boundaries.

Example 2: Triggering external communication after a job finishes

The work does not end when a workflow (or job) is complete. Jobs finishing successfully (such as backups or transcodes) often cause follow-up actions: informing the production office, notifying editorial, or simply confirming that footage is safely backed up. A post-step script can react automatically when a job finishes, for example, by sending an email that includes relevant workflow information, such as the job state and on which volume the data was written to:

1 function onFinish(_, _, workingPath, success)
2
3    local to = "production@example.com"
4    local subject = "Silverstack job finished"
5    local status = success and "Successful" or "Failed"
6    local body =
7        "The job has finished.\n\n" ..
8        "Working path: " .. workingPath .. "\n" ..
9        "Result: " .. status .. "\n"
10
11    local url = "mailto:" .. to .. "?subject=" .. subject .. "&body=" .. body
12
13    os.execute('open "' .. url .. '"')
14 end

This script will create an email draft without sending it. The email informs the recipient that the job has finished, including information about the job’s working directory (line 8) and the job result (line 9). You could think of many other valuable pieces of information for the email, but for the sake of demonstration, we keep this example simple.

Here, too, the emphasis is on controlled behavior. Post-step scripts can only be executed within post-steps that are started when the associated jobs finish, and according to the logic you specify. You determine which actions are triggered and under which conditions. By automatically embedding your own logic into the workflow, you reduce repetitive steps while maintaining oversight and responsibility.

Why scripting matters

These examples highlight a common theme: scripting allows you to extend and personalize workflows while keeping them consistent and overseeable. Instead of maintaining multiple slightly different workflows or introducing ad-hoc variations, you can keep a clean, structured setup and use scripts for the specific adjustments that reflect a production’s needs.

That said, scripting is not required to use Silverstack effectively, but it can be a valuable extension for cases where additional automation or customization is needed. Whether you are a data manager or DIT on set looking to reduce manual intervention and streamline your processes, or a company building custom tools around Silverstack as the main engine, there will be situations where scripts can come in handy. 

The script editor: where custom logic lives

To support this level of extensibility, Silverstack 9.2 introduces a dedicated script editor. It’s a place where you can create, edit, and manage your scripts without leaving the application.

The script editor is closely tied to workflows. You can work on a script while configuring a workflow, adjust it as requirements change, and reuse it across projects when needed. Scripts are organized into three locations, each serving a specific purpose:

• Default: scripts provided by Pomfort, which can be used as-is or as a starting point for your own adaptations
• Project: scripts that belong to a specific project and ensure project-specific reproducibility over time
• Shared: scripts that are available across projects to support consistent results for multiple projects

This structure reflects a deliberate design choice and supports reproducibility, traceability, and shared standards. All scripts are stored as regular files in the file system, allowing you to also access them with Finder and create versions as needed. Within the script editor, you can duplicate scripts from the default into the project or shared location, e.g., to start an iteration from the provided default scripts. 

Most importantly, the script editor is designed to make learning manageable. It includes an API reference and features such as auto-completion or a preview of the edited variables, helping you explore supported functions while staying within a clearly defined scope. That is why it was important to us to design an editor that allows users to create scripts quickly and interactively.

Yet, for those aiming to work on more complex setups, the script editor allows opening scripts in an external IDE of your choice. On top of that, technical users and developers can make use of shared functionality by creating modules that can be loaded with the help of require(). 

Conclusion

Scripting introduces a new degree of versatility to Silverstack’s workflow concept. It gives you a clearly defined extension layer to reflect the real-world challenges of your production without reinventing your setup. Silverstack continues to function exactly as it always has. Scripting simply gives you the choice to adapt it, but on your own conditions. Let us know: What would you extend in your own Silverstack workflows?