ScreeningRoom started off as basically a "what if" project, and has grown to be one of my most popular apps. It's gained a number of new features over a handful of releases but has remained, at the core, the same app that was started a little over a year ago. I'm happy with that core, creating a preview of to show monitors you might not be able to see, and don't see any reason to change it.
However, ScreeningRoom as it stands now has some, let's say, discoverability issues. The application lives only in the Menu Bar, which has lead to some confusion about where the app1 is and whether it's running. Depending on the display configuration dragging the popover to create a window can be nearly impossible and the context menu only UI leaves much to be desired.
Bug Fixes and Improvements
I've been working on a completely new version of ScreeningRoom that should address the outstanding UI issues. For starters it will be a normal application that, when launched, will show a normal window. Controls have been placed on screen so they're easy to find. Rearranging the interface like this also comes with some new features.
The control bar at the bottom of the window has options to quickly toggle streaming for all visible displays, speaking of which, displays can now be selectively hidden from the preview. This allows you to create windows for a single display as well as any combination of displays.
The rendering engine has also been given some upgrades, which are mostly invisible. One of the only areas you'll see the change is in the cursor crosshairs, which now render in the correct place2. The crosshair also renders across all displays, instead of just the display the mouse is in, which will should make the cursor easier to find.
The update is still a work in progress, but I'm hoping to have it ready by the end of the year.
This became readily apparent with the launch of the new MacBook Pros, which had less space for Menu items. In some cases ScreeningRoom wouldn't even be visible.↩
I'm pleased to annount two big updates to the Capture One Stream Deck plugin. The first is a new update and the second will make updates easier in the future.
Announcement the First
A new version of the plugin, 2022.6, is out and ready for download! This update fixes camera compatibility issues that prevented setting the shutter speed, aperture, or ISO. It also adds three new actions to toggle the visibility of the overlay, grids, and guides1.
Announcement the Second
After what has probably been too long I've finally submitted the plugin for inclusion in the plugin store. It hasn't been approved yet, but once it's in the store you'll be able to update automatically instead of needing to reinstall. Watch this space for an announcement when its available.
Unfortunately guides are Capture One Studio only, a limitation of Capture One's AppleScript support.↩
The photographer I’ve been working with the last few days has really liked the idea of getting a 9 up grid of images to page through, and obviously as that’s something that takes more than ~7 seconds to do I wrote a little script to do it for me. I think it pairs particularly well with ⌃9.
Way back with macOS Yosemite Apple introduced an API meant for cloud sync applications like Dropbox to be able to add badges to files and folders, and after finding an application called GitFinder which leverages theses APIs to do something other than sync it got me thinking about building an extension that adds common digital tech tasks directly into the Finder.
A very simple version would just add menu items for setting the capture folder and adding folders to favorites, but the Fun Version would also sync those states as badges. A couple days a I decided to really look at the extension API to see if I could build such a thing.
The short answer is "yes".
As part of myriad other projects I've built myself a fairly robust bridge between Capture One's AppleScript library and Swift. The bridge has its own mini-API for interacting with Capture One and handles converting AppleEvents to and from Swift objects1. The Finder Sync API is relatively straight forward, it asks you about files and folder and in return you tell it what badge to display.
However, because nothing can be so simple, one issue I ran into was actually interacting with Capture One. The app extension refused to send Apple Events, which I assume is a security measure. After looking into the docs a bit more I figured an XPC service, which lets you move some of the business logic into its own process, was the way to go. I've never built anything using XPC and making sense of the API required a fair amount of research2.
Eventually I did manage to get everything working. The extension adds menus for setting the capture folder, adding and removing folders from favorites, and viewing a folder in Capture One. Crucially it also adds badges for the current capture folder and folders that are in favorites. The badges will even update in (somewhat) real-time to reflect changes made in Capture One.
While it does work the entire thing feels incredibly fragile. The extension communicates via XPC with the launch agent, which in turn calls Capture One via AppleEvents, which may time out and never complete. Updating based on changes in Capture One requires a repeating timer rather than actually being notified of the event. There are a number of states that could easily get out of sync. Everything only works on the current document, and would almost certainly break if multiple were open.
Honestly this is something I would love for Capture One to integrate themselves. I can't imagine them doing so anytime soon, but it would be a nice feature that could directly benefit working digital techs.
I should probably publish that code into its own library.↩
For instance, Apple's own XPC template won't compile.↩
I'd like to introduce a new app I've been working on called First Contact, a quick and easy way to create contact sheets. First Contact features the right balance of options for customizing the layout while not getting you bogged down.
There are a number of ways to make contact sheets, but they tend to be part of expensive subscription plans, a side-feature of a DAM, a fancy print dialogue, or some combination of all three. First Contact aims to be fast and easier without sacrificing flexibility.
When you open images in First Contact the PDF is rendered in real-time, showing you exactly what you'll get and how large the final file will be, important if emailing is a concern. To that end you can also use 🥔 Mode, which scales images to the actual dimensions of the cell rather than embedding a larger (or full-size) copy.
The layout is easily customized by selecting the number of rows & columns along with the page margin. Your contact sheet can also be given the classic dark mode treatment for night owls.
Once everything is ready you can save the contact sheet and be on your way.
First Contact is available now for $25 with a 14-day free trial. To celebrate use the code first-contact-launch for 10% off!
Recently I've been working on building out a more reliable network for my cart. Anyone who's used Capture Pilot knows that it's temperamental at best and the ports are blocked by corporate IT at worst.
I used some spare Ubiquiti equipment I had after upgrading my home network and build a little "rack" that fits inside a Pelican 1300 case. The frame is made of NanoBeam, a 5mm T-slot extrusion beam, which is perfectly suited for the task.
Assembling the frame was tedious, all of the parts are comically tiny and easy to accidentally knock out of place before locked down. After the shelves were installed the whole thing is quite strong.
The final part was powering the USG and switch. Each has its own power supply, but I didn't want to need to run two cables. Reviewing the requirements for the USG I found I could actually run it with PoE via a splitter. To further simplify I ran a patch cable to a keystone socket so all everything connects like normal rack-mounted networking equipment.
I'm happy with how the project turned out and I've already put it into service on set.
Last year I released Capturebot Lite, an app designed to do one thing: create folders. Tonight I'm releasing the first major update of the year. This includes all of the usual Bug Fixes and Improvements one expects, plus some fun new features.
The headliner for the release is Manual Filenames. 2022.2 brings the ability to edit and remove them, but also the option to create repeating names for the shoots that don't require anything more than: Shot 1, Shot 2, etc.
The export processing order has also been tweaked a bit. Trimming characters is now the first step and changing the text case occurs before replacing whitespace. This allows for transforming filenames into CamelCase, for instance.
There are also a few UI updates, like rounding out some text fields and matching the order of the whitespace and illegal character replacement order.
The Capturebot website also has a new help section for Capturebot Lite explaining some of the specifics around import and export.
A while ago saw a link to some old LED hexadecimal displays, DL2416s, little four character modules that accept ASCII and have an LED matrix for the display. I was captivated by them and purchased a handful from eBay with the idea that I'd use them as a thermostat as part of my home automation.
Long story short, I designed a very flawed circuit board that I never quite got working correctly, and abandoned the project. Recently I decided to pick it back up and realized that not once had anyone needed to control the heating via a physical device, so I scrapped it and figured I'd just build a single generic 16-character display.
One goal I had was to minimize the visible PCB, which was tricky because of the through-hole sockets for the display modules. Eventually I decided on a two PCB design: one display module and one logic board for the microcontroller. This would allow the two PCBs to be mounted at 90º and give some flexibility for which microcontroller to use.
While prototyping everything on a breadboard I'd never used more than two displays simply due to the wiring complexity. Each display requires 18 pins, all of which are connected together. While I would have liked to installed all four displays, at the end of the day it wouldn't have mattered because I'd still be routing everything in CAD anyway with no way of knowing I'd done it transferred all of the wires correctly.
Once I got the PCBs back and soldered all of the components into place I was relieved to find I had wired everything technically correctly, save one issue that I probably would have found had I prototyped all four displays and a Raspberry Pi Pico instead of an Arduino.
Each digit is addressed with four pins: two chip selects and two digit selects. Something that took me far too long to realize is that when these pins are ordered correctly they make a single 16-bit number, one for each character. When connecting the pins to the Pico I simply matched the pin order of the displays. Had I thought about it I would have realized that placing the pins on adjacent GPIOs (like I did with the data pins) would have meant I could sent the digit enable in a single step.
Controlling the display is relatively simple:
Select the digit
Pull write low
Write the ASCII character
Pull write high
Similarly a cursor can be shown by setting the bit while the cursor write pin is low, and all cursors can be shown or not with the cursor enable pin. You can also blank the entire display.
With the hardware and basic logic working I next question was what to do with it. The first thing I did while testing reading characters over USB was build a simple terminal based on ASCII control characters. It also serves double duty by allowing a program to interact with the display.
This was also the foundation of the first "real" application: a serial clock. I updated a program I'd written for the 8-character breadboard prototype to make use of the full display and control characters. This worked, but came with the limitation that the Pico couldn't display the time on its own.
The Pico luckily has its own real-time clock (RTC), however setting that clock is a different matter. The simplest way is to just write a program that sends each date and time component bit-by-bit and reassembling it on the other end. On the Pico each component has a fixed length, so counting up the bits isn't too hard.
Letting the Pico handle the date has the advantage of not needing to keep the serial connection open and lets a launch agent reset the clock when the Pico is reconnected.
The Finishing Touches
The final thing I needed to do was find a suitable stand. I figured heading to my local fancy lumber yard and sorting through the scrap bin would be the way to go, and indeed it was. I found a rough hewn piece of ebony wood that really fit the dark PCB and red LEDs.
I proceeded to measure and mark out the length and holes for the standoffs. Unfortunately I decided to do that as the sun was setting and messed up the locations of two of the holes. I filled them and re-drilled, being much more careful, only to break off not one, but two standoffs!
After a couple of tries I got them all in the correct positions and everything assembled. I'm considering adding a bandpass filter in front of the displays, which according to the datasheet will help increase the contrast of the LEDs against background, and a nicer right-angle USB cable.
After, checks notes, three years without any updates I scrapped my original background script plugin and replaced it with a proper application. In short Capture One's plugin API isn't great nor was I even really using it as designed and recent macOS updates broke it the rest of the way.
The new app version of ScriptSetter also gains some new abilities like being able to set scripts for any installed version of Capture One (whether it's running or not), can actually be updated, and is properly signed.