Automation workflows with Monogram

The following was done with Monogram Creator (beta) and a set of the new Monogram Creative Console Studio tiles, in C1 v20.

This week I was lucky to enough to get hold of the new Monogram kit for evaluation. We sometimes get clients looking for a simple “push this big button -> do workflow” for reducing C1’s somewhat idosyncratic techincal cruft, and so I wanted to see if it could be a useful solution.

For the uninitiated, Monogram could be equated to a sort of modular “midi controller”; buttons and dials that can be assembled together into a custom controller panel.

Full disclosure, I have Tangent gear, which I love. Two reasons for looking at this set was:

  • Lower price point makes it easier to approach if you only need a few buttons
  • Desktop footprint is tiny, and more suited to some environments that don’t want full editing solutions (like eCom)
  • The kit I recieved included a new module (Orbiter) which can be used for color grading (different execution, but similar result to how the Tangent balls work) – otherwise the buttons, sliders, and knob modules from the previous generation kit return (albeit redesigned).

    New is the LED illumination on each panel (nice for insinuating function) and the colors are configurable via the new Creator application. The Creator software integrates well with Capture One’s editing tools and is pretty responsive. It also has the ability to emulate shortcuts.

    I’m not doing a full run down of what it does when editing, how it does it or why/if you need it. This is not a review post.

    This post is simply about how best to create a bridge between the devices and the automation capability of C1.

    Launching scripts

    Ideally I just want to press a button and run the automation, but there isnt native support for “run this script” in the Creator app. If C1 is focused you can of course emulate the shortcut to the menu item in C1, but if it isn’t, then a small change up in webbing the stuff together is needed.

    As scripts can be exported as an “.app”, and as scripts can be made to run “on open”, I found a solution:

  • My script saved as an .app
  • A shortcut – potentially global (one that works at any time from any app) to “open application”
  • Configure the button in monogram to emulate said shortcut.
  • As per previous posts on making applets and custom shortcuts the scripts are complied as apps and saved in Capture One’s scripts menu. They still work just like scripts – and can be invoked with your custom shortcuts.

    BUT – by saving the scripts as an app, they can ALSO be copied into the applications folder and launched just like a “real” application (as long as the script logic is within the “on run” handler).

    This also means you you get an extra benefit in that can launched like an application at any time by adding them to the dock. This is great if you don’t have CO focused – you just drop down the cursor to the dock and click-to-run.


    1. Save your script as an .app in your applications folder…

    2. Using this post on automator as a guide, create a service to open the app…

    3…. and add a shortcut to the service…

    4. Configure monogram creator to call the same shortcut you set to the service in the system prefs…

    You now have a simple button that will run the automation at anytime from anywhere!

    About Monogram

    Monogram was formally Palette Gear. This set is part of their second gen hardware and software. You can find out more about Monogram here.

    Get Started With AppleScript – Conditional Processing pt1

    The following project/idea I originally produced for the Project Lemonade series for Digital Transitions webinars. The following is a short version of it, if you want to see the full webinar visit and sign up to the DT archive here.

    Before we get started…

    For part 1, we will concentrate on writing the script as if we are mirroring the same logic of using Capture One UI and UX concepts. I’m fully aware there are several approaches, model shortcuts, logic and advanced syntax to ultimately achieve the same results.

    However, this “parity” method I have found is a great way to learn the concepts of scripting Capture One, without blowing your mind on day 1. It also helps underline the moving parts within Capture One. Once we have a good base we can look at the advanced stuff and change up the gears in pt2 and pt3.

    The reason for pearoasting this is, it is a good project covering many of the core/fundamentals of Capture One scripting:

  • Code block
  • Comments
  • Variables
  • Operators
  • If/else statements
  • Selections
  • Commands
  • If you are new to scripting, check out our other posts on getting started.

    Let’s start!

    Conditional Processing

    Why automate processing? Processing/converting images – from RAW to an RGB image format – in batches is fairly well supported in Capture One as a feature. You might ask why you would want to automate it further.

    The kind of case where this makes sense is when the requirments change to more than just: “process everything as TIFF”.

    What if there are certain recipes that should act on images with certain properties? For example, if the image has red tags, process it to here; if they have a certain meta data, process them only as Jpeg.

    This kind of problem occurs in more production type environments where you might need extra dynamism – or one where your users dont have technical accumen to select/deselect the necessary images, switch on/off or change recipes paths and so on.

    This kind of scenario is when errors happen, and errors at scale are expensive.

    Luckily, this is great example of something we can automate!


    Open a new script file in your IDE and paste in the first bit of code below. Use ⌘+K to compile.

    This is what we refer to as a tell block. In AppleScript code blocks start with tell and close with end tell.

    When addressing the application, we always start with “tell “. This directs the script to the application “object”: the first object in the “application model”. All the code between this tell/end tell is directed at the application in question.

    AppleScript is an “object orientated” language. Understanding the model of how the objects are arranged and inherited is key to making scripts for Capture One.

    A good analogy for this is to think of it much like a russian doll. The biggest object is the Application. This contains the next biggest object, the document (session or catalog), which contains the collections (favourites, albums, folders) and these contain variants/images. This is called “object inheritance”.

    As the scripter, we have to make sure our commands are directed to the right objects, and this requires navigating the “levels” of the model in the code.

    As per previous article ScriptDebugger is recommeneded for many reasons but one of the stand out reasons for me is the object model view in the dictionary. This is great for inspecting objects and viewing the model of any AppleScript capable model.

    Next, within the tell application block, we now need to talk to the next object in the model – the document.

    Much like as if you opened a session to see some work, we want our script to work on the document in front of the user.

    As we are only interested in the document we are working on we can use a special object “current document” – this refers to the application’s top most open and active session or catalog. Again we use tell to direct the script to the document object.

    The point of this script is to only process what we are seeing in the document, much like as if we were to do it manually. In order to this next bit, we need to understand about targeting the right “variants” for processing, then committing those to the batch queue.

    Our script so far is talking to the document level, but when the user interfaces with images in the UI, you are always in some sort of “collection”. This can be a folder, album, favourite or any other “container” concept of Capture One that holds images.

    As with current document, there is another super useful object to the collection currenly selected in the UI and thus being viewed by the user – current collection.

    Again, we nest within a tell block.

    This makes sure that the script is only targeting the variants for processing that are A: in the document we have active, and B: in the collection we have selected within that document. Again, this is mirroring somewhat the intended user experience of Capture One’s app design.

    The next part is really a design choice – you could decide you want the script to work on every image in the collection regardless of selection, or just on a number of images selected by the user. So we don’t break character with our user experience/parity mission, let’s work on the user selection.

    “variants whose selected is true” is a newer syntax from v11 onward, and replaces “selected variants”
    This syntax returns a list of variant objects.

    The repeat (control statement) is designed to loop through the code nested within it, x number of times (which in this case is equal to the number of variants we have selected in the UI). theVariant thus becomes the next variant in the list in each loop.

    We use it here as we want to check every variant given to the script. What to check it for, is defined in the code between repeat and end repeat. As theVariant becomes a variant object we can now use a tell block to talk to it as if we we talking to a variant directly.

    We are now at the fun part, where we decide the design what we want to do with each variant our script encounters.

    Let’s use an IF statement to decide a condition. IF statements only execute the code in the block if the IF equates to true. You can extend IF statements with additional conditions using ELSE IF, which if the first IF equates to FALSE, will run next. You can also use an ELSE statement; if all of the above is FALSE, do this.

    What to check is TRUE is a good question. A simple example is color tag. Ben Liddle looked at color tag peculiarities in his post here, but the short of it is, Capture One uses the numbers 1-7 to represent the colours Red-Purple. In doubt, think of how a Rainbow looks, and count in from Red.

    Note also the — following the first IF. This is an (inline) code comment.
    This allows the scripter to write anything after the line as a comment as to what you were doing or other useful notes that might help decipher what was going on when you come back to it later. Inline comments must be made after the code, not in the middle. You can also start a new line with — and this will also compile as a commented line. Commenting is also useful for removing redundant code, or excluding troublesome stuff when debugging.

    We thus check (in the first If statement) if the color tag is 1 (RED). if it is, then line after will execute. If it isn’t, the code skips to the next ELSE IF and checks if the color tag is 4 (GREEN). If it is, the line after will execute; if not, we go to the final ELSE (the garbage collector) which will set the color tag to yellow – indicating unprocessed.

    But what of our images that were GREEN or RED?

    The process command is added last. Process has two parameters: a list of variants to be processed, and the name of the recipe to use. For RED images, I want the script to process using the recipe “JPEG”, for Green, I want to use the recipe called “TIFF”. For variants that are neither, I will mark those Yellow, just to let me know these weren’t processed.


    You need to have your recipes defined in Capture One interface and named accordingly. This script is only “pulling on the handles” and assumes the recipes exist. We should make our scripting more robust and check the recipes exist before running – hell maybe even remake them if they don’t, but this is for another day.

    This script is now fully functional, and can be installed and executed from Capture One’s script menu as per this article.

    Get Started With AppleScript – Scripting Selections

    An intro series to scripting Capture One, with Ben Liddle

    Splitting hairs: Variants v. Images

    The thumbnails in Capture One’s browser pane are technically variants. A variant is a unique set of rendering instructions for a given source raw (or TIF, JPG, etc) image file. These instructions are lightweight (few hundred Kb at most), so you can think of these as virtual copies of your image files. Every image file you view in Capture One has at least one variant; unless you objectively create a new variant, there’ll be a 1:1 ratio of variants and images in your browser.

    Setting up the Handler

    Below is the code to set up the AS hander. Create a new script file and save this to the top of the file. Handlers are basically bits of code that you can call from anywhere else in the code (once you have already defined it, thus putting this at the top). They start with the on keyword, and are called with my (when they’re located in the same .scpt file as the code that’s calling it, but you can ignore this for now).

    Let’s break it down:

    Here, I’m declaring that we’re creating a handler arbitrarily called select_vars. The bit in parentheses is a parameter that I’m declaring. Basically, when we call this handler later on, we’ll be passing a variable as well. The ‘as string’ tells the script that whatever I pass to select_vars later on, it must be a string; eg if later on I pass it an integer or list, we’ll get an error.

    The color tags in Capture One are scripted to numeric values between 1 and 7. Here, I’m building a list of readable color tag names in their order: a red tag is actually a 1, a green is actually a 4, etc.

    Repeat with a variable i, from 1 to the length of (ie count) of the color tag list. On each loop through (iteration), i is the index (position) of the item in the list.

    Here we’re checking if the item in position i is the same as the text variable I’m setting. If so, create a new variable called color_tag_number and set its value to the current iteration’s value of i.

    Collect all variant objects of the current collection whose property color tag’s value is equal to the value of color_tag_number . Create a new variable, sel_vars, to store references to them. Since we used the plural of variant, our variable sel_vars is a list.

    The current document is being told to select the variant objects referenced in sel_vars. This is actually an additive select- if we had four other variants selected, we’d have the count of green-tagged images plus those four selected. This can be prevented by throwing in a deselect command before the new select command:

    With this handler set up, we can call it wherever we want in the script without repeating the code block:

    Et voila. Variants selected.

    Ben Liddle is a data manager in Colorado who automates the shit out of the first half of the work/life balance so the second half can be more fun.

    Get Started With AppleScript – Basics

    An intro series to scripting Capture One, with Ben Liddle


    Years ago, in a warehouse in deep industrial Brooklyn, I was a digital technician on an e-commerce photo shoot struggling to stay awake. It was 3:30 in the afternoon on a crisp winter’s day, and the stylist was diligently stringing up the 80 billionth (by my estimate) crossbody’s strap of the day. The photographer was (probably) retouching his latest editorial job on his laptop in the corner. I was working with Capture One Pro 8 (iirc, maybe it was 7, honestly there wasn’t much difference for this workflow), and pulling up yet another go-by for styling reference. It was one of those shit days where you arrive on set at call time before sunrise and just know in your bones that you’re not leaving before sunset.

    As an aside, if you’re reading this and you were on set that day, I don’t mean to offend. I look back fondly on those days, those mid-shoot conversations, the catering, but I think we can all agree that it wasn’t the most enthralling of experiences.
    The actual “work” I was doing on that job was mostly completed in the setup day from the week earlier; after that, it was scan the barcode, create a new Capture folder, name the capture folder, reset the capture counter, set the camera to Live View, set up the proper go-by as an overlay, make sure the stylist can see the Live View, take test shots, check focus, color tag images, process, comp in Photoshop, hit Chronosync, rinse, repeat ad nauseum.

    If you’ve worked e-commerce, you probably had a similar flow.

    I did this for years and years to pay rent, in between the “fun” jobs that filled up my passport pages. I figured there had to be a better way; a way to be lazier, yet not fuck up. Just do less. Fast forward a few years, ~13 versions (Capture One 20-Capture One 7=Capture One 13, the math checks out, fight me), and there’s little from that day on set that can’t be automated. Well, afaik you can’t automate rigging a crossbody strap to match the 799,999,999,999 previous, but I digress. My heart goes out to you still, stylist.

    Heads up!

    I’ll be using Capture One 20, since it’s known to be the most scriptable of the Capture One versions. If you haven’t tried Capture One 20, you can get a trial at
    If you’ve made it this far and are on Windows, I’m afraid I can’t help you achieve peak lazy. As of this writing, only Capture One on macOS (and OSX, if you’re feeling retro) can be automated via scripts.

    Capture One can run .scpt files in AppleScript (aka AS), Javascript for Automation (aka JXA), and AppleScript-ObjC. Frankly, I’m most comfortable in AS, have fairly extensive experience with JXA, but little/none with AS-ObjC. There’s obviously syntactical differences between the three languages, and for the purpose of these articles, I’ll be dealing mostly with AS.

    For the rest of this story, I’ll be doing a bit of beginner’s intro to AppleScript and Capture One. If you have experience with AS, I suggest checking out the next post in this series: Selecting Variants and Images

    Hello, World

    As an introduction, we’re going to write a basic Hello, World to illustrate running scripts in Capture One. There are many, many IDEs (Integrated Development Environment, basically software for writing code) out there. For AS specifically, I’ve used a few:

    Script Editor: already bundled with macOS. Simple. I’d say use this to get your feet wet, and for the first few stories I’ll be screen-shotting from this.

    Atom ( Open source text editor that can do just about… anything? You’ll need a few extensions to get it to parse/compile/execute AS, but it’s pretty.

    Script Debugger ( My preference. Extremely verbose and powerful. Not free though, still a bargain at any price if you end up creating any complex automations, especially if they involve multiple applications.

    Open up your IDE and create a new script named hello world.scpt.
    Here’s the code we’ll be adding. Note: comments in AS are denoted by starting with — . Comments are blocks of the code that aren’t actually run and are used to explain what’s going on.

    Press cmd+k to compile the script. If it compiles correctly, you’ll get indentations, syntax-based highlighting, the whole works. If not, you’ve made an error.

    Hit the Run button to run the script.

    Congrats. That’s AppleScript 101. You can find more on the basics here:

  • Mac Automation Scripting Guide (from Apple)
  • Introduction to AppleScript Language Guide (from Apple’s documentation archive)
  • AppleScript Beginner’s Tutorial (from
  • Hello (name of document)

    Let’s start working with Capture One directly to get the name of the document; your session or catalog database file:

    It’s worth pointing out here that the above code has the display dialog verb within the tell current document block. Because it’s nested, the current document is the one calling the display dialog. Any further interaction with the current document is blocked until that dialog is cleared (one of the buttons is pressed). This code appears to result in the same actions, but since display dialog is outside of the tell application and current document blocks, it’s the OS that’s calling it:

    Because we stored the document’s name in the variable doc_name, we can extract that data and use it anywhere we like!

    That’s a good enough intro. In the next story, we’re diving into some more complex workflows.

    Ben Liddle is a data manager in Colorado who automates the shit out of the first half of the work/life balance so the second half can be more fun.

    Wrap beers

    To close the year out we thought we would end with an “off-topic” post on something close to every digi’s heart: beer!

    Inspiration for the is post comes via an annual TV show we get in Denmark (which is very, VERY Danish) – the Natholdets Julekalender.

    The premise for the show is quite simple: Beer expert Carsten Berthelsen takes Anders Breinholt (a sort of ginger Jimmy Falon/Jonathan Ross) and Søren Rasted (keyboardist from the band Aqua) on a “våd rejse” (wet journey) to decide which are a best three christmasy beers for 2020.

    The show is recorded in one day, and a beer for every day of advent (24 total, pre-selected by Berthelsen) are tried. Every 5-10 minutes a new beer is provided in a glass which they must taste – along the way they choose the top 3, which is placed up front on the mini podium.

    They are allowed toilet breaks, but no water. In addition to the beer, there are 4 “Advent-Sunday days” and this also requires a Schnapps shot be taken. The result is something you probably wont see anywhere else – three grown men, absolutely ratfucked trying to hold together a tv show.

    That all aside, the beer list is actually an impressive offering from Denmarks microbrew/craft scene. The full list is below. At the time of writing (afsnit 18) the best 3 beers were:

    • Thisted Bryghus: Julesten (Strong Ale) – 8 % (1st)
    • Bryggeriet Åben: First Light (New England IPA) – 6 % (2nd)
    • Herslev Bryghus: Juleøl (Red Ale) – 6 % (3rd)

    Full list:

    • Nørrebro Bryghus: Bombay IPA (West Coast IPA) – 6,5 %
    • Bryggeriet Åben: First Light (New England IPA) – 6 %
    • Viborg Bryghus: JuleBocken (Doppelbock) – 7,3%
    • Beer Here: Ammestout (Milkstout) – 6,5 %
    • Alefarm Brewing: Decorations (Pale Ale) – 5,2 %
    • Midtfyns Bryghus: Funky Santa (Imperial Brown Ale) – 8,5 %
    • Kissmeyer: Stockholm Syndrome (DIPA) – 9,5 %
    • Flying Couch: Icebreaker (New England IPA) – 6 %
    • Skagen Bryghus: Klitnisse (Doppelbock) – 6,8 %
    • Mikkeller: Sally, oh Sally (Kölsch) – 4,9 %
    • Bryggeriet Skands: Blå Chimpanse (Dubbel) – 6,5 %
    • People Like Us: Oats of Disobedience (Havrestout) – 5,3 %
    • Thisted Bryghus: Julesten (Strong Ale) – 8 %
    • Braunstein: Dragonfly Coffee Bean (Kaffestout) – 9 %
    • Timm Vladimirs Bryghus: Pale Alene i Verden (Pale Ale) – 5 %
    • Grauballe Bryghus: GunsmOak (American-style Ale) – 7,8 %
    • Herslev Bryghus: Juleøl (Red Ale) – 6 %
    • Syndikatet: Hippien (Imperial Saison) – 10 %
    • Aarhus Bryghus: Juletønden (Strong Ale) – 8 %
    • Hancock: Julebryg (Doppelbock) – 10,5 %
    • Albani: Blålys Juleøl, Jubilæums Craft Version (Doppelbock) – 7,5 %
    • Hjort Beer: Brown Bella (Dubbel) – 7,4 %
    • Bryggeriet FRANK: Sinterklaas in Space (Dubbel) – 8 %
    • Amager Bryghus: Secret Santa (Quadrupel) – 10,5 %

    We found a vendor selling a “kit” online, sadly they were out of stock by the time I got this up.

    Capture One shortcuts for the terminally curious: part 3 (Final)

    We have arrived at the final part of this series: the script!

    This is a simplified extract of the full installer application I made, as it is simply far too big to break down into a single tutorial. Instead, I have made a fully functional version of the useful part, which does most of the heavy lifting and annoying bit – adding the shortcuts to a set of installed scripts.


    • Quit C1.
    • Make a folder in ~/Library/Scripts/Capture One/Scripts/
      • (For my example today: ~/Library/Scripts/Capture One/Scripts/Apply Latitude)
    • Copy your scripts into this folder – for this, I am using scripts from another project post to come in the new year – yours will be whatever you make.

    My scripts are called:

    • “Apply SB-01.scpt”
    • “Apply SB-02.scpt”
    • “Apply SB-03.scpt”
    • “Apply SB-04.scpt”
    • “Apply SB-05.scpt”
    • “Apply SB-06.scpt”
    • “Apply SB-07.scpt”
    • “Apply SB-08.scpt”
    • “Remove Style.scpt”

    You need to decide what the shortcuts will be, and you need as many shortcuts as there are scripts (9).

    Next we need to map these together as a “value pair” for the script.

    As a reminder on the first post in the series, coding shortcuts requires a bit of symbology to equate user facing stuff: Modifier keys are represented as: @ for Command, $ for Shift, ~ for ⌥ and ^ for ⌃.

    So the string “@$~^t” represents ⌘+⇧+⌥+⌃+T

    Im going to set these up as the full ⌘+⇧+⌥+⌃ + [key]. This is obviously impractical for a users, but it serves as a technical demonstration (and actually doesn’t matter in the other project). You might decide to use something else:

    • “@$~^A”
    • “@$~^B”
    • “@$~^C”
    • “@$~^D”
    • “@$~^E”
    • “@$~^F”
    • “@$~^G”
    • “@$~^H”
    • “@$~^I”

    Now you have the list of file names, and the list of shortcuts, we have to combine this into an object the script will parse into the shell command.

    The simplest way (IMO) to do this (and there are many methods) is to make a list. As we have to make many value pairs, we could go one step further and make a list containing the smaller lists.

    A list in apple script is defined with curly brackets:

    To define the first value pair, combine the script name and the shortcut (“” makes them text values) and then split with a comma.

    We could add more pairs to a single list, but this would be suboptimal. Instead we create a list of lists (a list containing several smaller lists) by puting the another pair of brackets around the first. This gives you a main list, containing each of the value pairs as addressable items within it.

    When completed, it should look like this:

    Which is basically a list containing a number of text value pairs, each as their own little lists of 2 items.

    TIP: You can line break long lines of code by placing the cursor and using ⌥+[return] – this makes reading and editing long lines easier.

    When testing, you can now ask for a value pair from the list easily:

    Which returns the 3rd item – {"Apply SB-03", "@$~^C"}

    The script also needs to know the name of the folder you made your scripts in (seeing as we are using the full path approach to the shortcuts).

    Create a new variable and assign the name:

    Next we have to make some logic that will chop the value pairs for each row, and then run the shell command with those bits. A repeat loop can be used to cycle through the list, and extract the name and the shortcut from each pair by creating new varibles from the indexed position. Comments have been added to the code below explaingin each line (those lines starting –)

    There are again, a few ways to do this. I used this approach:

    The last part is the shell command, and is fairly advanced if you have no experince in scripting shell in AppleScript, requiring skills like string concatination, charcter escaping… and massive patience. I do conceed, I should maybe have started this this blog with a gentler slope, but what can you do. Stuff tumbles out when it does.

    The shell command from part 2 was:

    You can type this into terminal and it will work – but it wont if run from within AppleScript.

    Shell commands from an AppleScript are invoked from the “Do shell script” command – this recieves a single text paramater between “”. Because our command has several ” between the first and last ” the script interprets the code inncorrectly. To stop this from happening we need to escape certain characters so the script ignores them, but will still pass them to the command line. To do this, charcters we want, but want AppleScript to interpret as just text, are proceeded with “\”.

    We also – and at the same time (bloody hell) – have to inject our variables into the text. This requires replaceing stanadrd text with the varibles and then concatenation of the various elements together with “&”.

    So with all 3 variables, escaping and the new command, our script looks like this:

    Our script is now complete. Running the script will add the shortcuts to (in this case) Capture One 20.

    The script from this post is below in full, if you want to copy paste this to your own IDE and start breaking stuff, go nuts.

    If you screw up your C1 plist you can reset the custom shortcuts entry by using the following terminal command:

    I hope this has been an interesting series – we have tonnes lined up, but I wonder what should be next?

    Leave a comment after the break.


    How to make a script applet

    Making a script applet is not much harder than actually making a script – from the outside the extension changes to .app, and the app when clicked will “run” rather than open in script editor. Mostly useful.

    I use Script Debugger for all my AppleScript work. It’s a billion times better than Script Editor. Specifically for applet design, it makes life simpler for adding and removing resources, and you can also add your icons and developer ID easily. You can do this in Apples’ Script Editor but for the uninitiated, it is a journey of questions, throwing things and swearing.

    Start a new script from File > New Script and choose Application> Applet in the Script Template tab:

    Once open you will see the following:

    You can add script resources (files, icons, libraries and other scaffolding) using the “+” icon within the bundle tab (suitcase icon in the toolbar). Make sure to save your applet before you add, as it can get squirrely adding resources when its still in memory.

    In the example here I’ve made an .icns file (a new icon for the applet) and added a folder containing a text file, and a snippet of code for demo.

    Once added you can choose the .icns file as an alternative to “applet”. This gives the script a nice custom look so it looks nice and shiny on the mac.

    The code in my applet is very simple – this just demonstrates some syntax to get the path of x resource, then show it on screen for the user. The standard additions command “path to resource” is important, as we will want to use the paths in the final project for copying the resource from the bundle, to the destination Mac.

    For the final project in Capture One shortcuts for the terminally curious I want to build an applet that will install the scripts for my guy, plus add shortcuts to them. An applet is perfect for this as I can bundle all the resources I need in the applet (making it super easy to distribute). Another goal was to have the project reusable for other clients/projects so I don’t have to spend hours changing key value pairs in xml or escaping super long shell scripts because the clients use spaces in all their naming.

    Capture One shortcuts for the terminally curious: part 2.5ish

    I was just about to conclude the the shortcuts series and getting to the point, when I realised I may have approached the flow of this project ass-backwards, as there are a lot of other moving parts that make this whole endeavour more relevant if understood first. So, if you have never done this stuff before I should probably ALSO write about these other things.

    So, to frame this properly and hopefully make this a more, rounded and useful experience, there are two other topics to dig into. Each of these is now its own post, and you can find the links below:

    How to install and use scripts with Capture One

    How to make an applet

    The ultimate point (of the Capture One shortcuts series) was this: part of what I make for my clients ends up as “script bundles”. That is, I create a number of scripts, each designed for different actions.

    If you don’t know, “scripts” in Capture One is as to Actions in Photoshop – they are designed to cut time from repetitive tasks.

    Stuff I have written for Capture One includes:

    • Barcode scanning extensions
    • Renaming macros
    • Case dependent processing
    • Metrics and reports
    • Notifications
    • Excel integrations
    • Workspace and session templating
    • Specialised workflow design
    • Metadata manipulation

    Most of these interact with Capture One in some way or another, and usually will need to be executed on demand.

    In nearly all cases, the best way to do this is with a shortcut to run the specific workflow – and you sometimes need many of these. As per the shortcuts post, Capture One itself does not (and why not is a mystery) offer the user the ability to shortcut scripts, styles, or indeed any other user generated menus. The work around does work for scripts (and this is the method I use to help my clients) but it’s not scalable to install multiple machines without automation – or when I have to build new applications for new clients and all the menus change.

    This requires a solution to package the scripts in an “installer” and somehow add the shortcuts to said scripts when they are installed to the users workstation…

    Have I arrived at the fucking point? I hear you ask. Well, sort of.

    The last piece of the puzzle is the “installer applet” and the point of all this effort, will conclude with a “How to” post on how to make it (when I’ve finished it).

    Watch this space.

    How to install and use scripts with Capture One

    There are a few ways to have a script execute and “do its thing” with Capture One. From easiest to hardest:


    Copy the script to the CO scripts folder.

    Simple scripts can be run straight from Capture One’s application script folder. Once installed, these will appear as a menu item in Capture One and is executed by selecting it like any other menu item (this method works well if you want to shortcut your scripts, as per the shortcuts article here).

    To use this framework:

    Open the scripts folder from inside Capture One (or navigate to ~/Library/Scripts/Capture One Scripts/)

    Finder view:

    Copy your scripts into this folder. If you copy in sub-folders containing scripts, then these will automatically be represented as drill down menus in Capture One.

    Once added, choose, “update scripts menu” from inside Capture One to make sure the scripts are loaded.

    Scripts should now show as menu items. You can add shortcuts to these manually as per the How to shortcut almost anything in Capture One


    Save the script as an “app”

    This can be run from applications (and can be added to, and launches like, any other app from the dock).
    Script Applets are effectively an encapsulated script plus all the necessary bits and bobs. If your script requires to be self contained – like an installer containing all you resources, uses other libraries or even app artwork like icons etc, then this is the solution. This is in effect a very simple version of what real developers ship in commercial software.

    Script applets can also be saved in the CO menu and run just like a script, so this is the best solution for commercialising scripts. We will use this method for the shortcut installer project.

    See the article on making applets here.


    Set it as an event.

    Capture One has a number of events: things like capture did happen, processing finished, etc. You can utilize these to trigger your script: e.g. Processing finished, email Roger in retouch to say his images are ready on the server. This happens sudo-magically, at least, once set. Capture One will just call your script automatically every time the specific event occurs. But there is a bit more work to get to that point… perhaps this is an article for for another day.

    Capture One shortcuts for the terminally curious: part 2

    In part 1 I ended with the idea of using this in to some AppleScript routines but hit a number of design issues with the syntax:

    1. Writing everything as a single list is not ideal for scalable or re-useable code.
    2. The syntax doesn’t really lend itself to scripting routines
    3. The big list was a LOT of escaped text and a pain to edit
    4. The main problem – the methodology if run again (say for another project) would replace any existing shortcuts, rather than appending. Less than ideal for building or adding to a set of shortcuts.

    Fortunately I recently found a second approach which solved all of the above.

    This changes the syntax a bit, but most of the existing work can be reused (for the specific menu drill down using \033) and the shortcut notations (like \UF70D for F10)

    To break down the improved syntax:

    1. The command and domain remains (defaults write com.captureone.captureone13 NSUserKeyEquivalents)
    2. This is followed by the specifier for add new key/value pairs to the dictionary (-dict-add)
    3. Then this is followed by the value pairs of menu title and shortcut (in quotes, separated with space)
      e.g. “\\033Scripts\\033My Folder Name\\033My Script” “\\UF70D”

    A full command (including escaping) now reads:

    This new approach means you can chop up this command line in a “do shell script” with some injected variables, and each and every invocation will add the shortcut to the dictionary.

    Still a bit to do for the working script but will try to make that the next post!