Resolve & Colour line · stop 08 of 14 · 34 min · members
Two hundred functions nobody uses because the documentation hides them. The twenty that matter.
Free with an account
Membership is free: an account opens all 86 script pages. The Lab, Studio Canvas and the paid guides need the $99 pass, paid once. Already signed in on this browser? The page opens by itself.
What it is
Poorly documented, entirely capable, and almost nobody uses it.
Resolve exposes a scripting interface covering most of what the application does: creating projects, importing media, building bins, laying clips on timelines, adding markers, reading and setting grade parameters, and rendering.
It is not well documented, which is the main reason it is unused. The documentation exists as a text file shipped with the application, and it reads as a reference rather than a guide, so most people open it once and close it.
What follows is the practical subset — the objects you actually need and the order in which they connect.
Connecting
The application must already be open; the script attaches to it.
The entry point is a module Resolve installs. Getting from there to a timeline is a chain of objects:
resolve = GetResolve()
pm = resolve.GetProjectManager()
project = pm.GetCurrentProject()
pool = project.GetMediaPool()
timeline = project.GetCurrentTimeline()Each level gives access to the one below. Almost every script begins with some version of this, and most errors at this stage mean scripting is disabled in preferences or the application is not running.
On the free edition, enable external scripting under system preferences before anything will connect.
The useful set
Three objects cover the majority of practical automation.
Media pool — import files, create bins, move clips between them, append clips to a timeline. This is where project assembly happens.
Timeline — create, list tracks, add markers, get and set the current frame, and enumerate items.
Timeline item — a clip on a timeline. Read its name, its duration and its position; add markers to it; access its grade.
Between them you can build a whole project from a folder: import, organise into bins by rule, append in order, and mark shot boundaries. That is the bulk of the clerical work in preparing an edit.
Grading from a script
You can address a node by position, which is only useful if the position is predictable.
Timeline items expose their colour nodes, and you can read and set parameters on them. Adjusting exposure on every clip in a timeline is a loop.
The requirement is that the node you want is always in the same place. On a project where every clip has exposure in node one, a script can find it reliably; on a project with variable trees, it cannot, and the automation is impossible.
This is the strongest practical argument for a fixed tree: not tidiness, but that a predictable structure is the only kind a script can work with.
Practical limits
The API is capable and it is not complete.
That last point is not a suggestion. Test on a duplicate project, always.
Where to start
A read-only script teaches you the object model with nothing at risk.
Write something that connects, walks the current timeline, and prints each clip's name, duration and position. It does nothing and it teaches you the whole chain of objects.
From there, add marker creation — still low risk and immediately useful. Then bin organisation. Then assembly.
Build up in that order and you will have a working understanding within an afternoon, which is considerably faster than reading the reference file end to end and considerably more likely to stick.
1:1 · two hours