Event Scripting
Events are the coolest way to utlize automation scripting, however the infrastructure for it is complex and pretty impenetrable for the uninitiated, so I wrote this article.
The idea of events is that Capture One will initiate scripts automatically and repeatedly when a particular event happens. This means you can develop and extend Capture One’s behaviour to be reactive to certain repetitive conditions. Examples might be:
The events are usually only needed to be set once – which is great as it becomes a fire and forget type configuration.
There are several “event” properties in Capture One (which once set) will react to specific processes.
The current list of available events are:
Barcode Scanned (v12.1 Enterprise only)
Runs (a script) when a code scan is completed
Example: turn the barcode into a capture folder
Import Done (’21 14.0.0 onward)
Runs (a script) after every Import event is completed
Capture Done
Runs (a script) after every Capture is taken over the tethered connection
Example: automatically process the capture
Batch Done
Runs (a script) on completion of a batch of images (processing)
Example: send an email to the retoucher when the job has finished processing to the server
Processing Done
Runs (a script) after every image in the batch queue completes
Example: pipe the resulting single file to additional processing in ImageMagick
Live view Done
Runs (a script) when Live View is closed
Live view will Close
Runs (a script) when Live View is about to Close
Live view became ready
Runs (a script) when Live view has become ready
How to use event scripts
To configure these events, you actually need two scripts (there is no official way to do it in UI): a script which sets up the event property with the script to run (A), and the script that runs when called (B). The example below is for Barcode Scanned, but the principle is the same for all event properties.
Fellow automation guru Emory Dunn has actually made a plugin for bypassing this step and setting scripts – kudos sir – this should really be in the application. Get it here!
The workflow though without this for the user will then be something thus:
Setter
This is an example script which “assigns” the script to the event property.
In this example the setter script (A) is designed as a toggle, and is kept in the same directory as the event script (B). Doing it as a toggle, means you can run it once to turn on the behaviour, and again to turn it off. You can reuse this for all event types by just making sure you change the right event property and script name.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
tell application "System Events" set scriptFolder to container of (path to me) set invokeScript to (file "myScanScript.scpt" in scriptFolder) as alias end tell tell application "Capture One 20.0.4" if barcode scanned script is missing value then set barcode scanned script to invokeScript else set barcode scanned script to "" end if end tell |
Event script
The next part is the event script (B) and is saved as myScanScript.scpt in the same directory you keep the setter script.
|
1 2 3 4 5 6 7 8 |
tell application "Capture One 20.0.4" -- the script runs when a scan happens, so the next thing to do is get the value that was scanned... set getBarCode to barcode of current document -- now you have the barcode stored as "getBarCode" you can then design the rest of the script here... end tell |
Commercial application
Should this be interesting, but you don’t want to make it yourself, I currently have two “event products” in the web-shop based on this technology, with commercial application: