Extending Reason with Hammerspoon

I make all of my music in Reason, which is a bit of an outlier in the DAW space these days. It’s staunchly devoted to its simulated hardware aesthetic, with the rack and the cables and whatnot, and it’s always been a bit sluggish to adopt widely accepted technologies like VST plugins. That said, it was one of the first DAWs I ever used, and it still feels like home to me, so I’ve dealt with all its issues and pushed through. When I started learning Ableton, however, I realized how much more customizable its workflow was, and how much I was missing in clunky old Reason. Maybe Reason itself was resistant to change, but I wondered just how far I could stretch its limits to make it work the way I want it to.

Hammerspoon is a nifty piece of software that lets you automate a wide variety of macOS stuff with its Lua scripting engine. I use it for a variety of simple things that make using the computer a bit easier, but I felt that its robust UI scripting tools would make it a great fit for a software like Reason which has very limited external control options. I decided to build an extension for Reason similar to the now-discontinued Live Enhancement Suite to enhance my workflow.

Minimizing hand movement

Two things I’ve spent a good deal of my life in front of are FPS games and modal editors. In the former, your left and right hands are interminably married to the WASD keys and the mouse, while in the latter using the mouse at all is considered gauche. In both cases, optimizing the distance your fingers need to travel to accomplish something is a necessary part of the process.

DAWs, and most creative software programs in general, are not very conducive to keyboard-only operation - especially for one as skeuomorphic as Reason. Therefore it’s best to assume that the left hand should stay in one place on the keyboard while the right hand should be on the mouse, and any actions you want to perform should require a minimal amount of movement.

I addressed this by creating a set of overlay keybinds for each of Reason’s three views, all mapped to the Ctrl key so as to not interfere with any existing ones. There are three main views in Reason: the mixer, the rack, and the sequencer. It’s possible to view two or three of them at a time, but I find this cluttered and confusing in most cases so I usually just have one maximized at a time.

toggleMixer = { { 'ctrl' }, 'q' }
toggleRack = { { 'ctrl' }, 'w' }
toggleSequencer = { { 'ctrl' }, 'e' }

For each of these layers, a subset of additional binds is activated that are specific to that view. This allows me to reuse keys and keep as many binds as possible on the left side of the keyboard.

A notably annoying key to press with the left hand is the Delete key, which is all the way on the right. Since I use a five button mouse, I decided to map Mouse5 to Delete and Mouse4 to M (which mutes clips), placing selection, deletion and muting entirely on the right hand.

Creating devices

I really like how in Ableton you can press Cmd-F to instantly search for anything you want. I wanted a similar experience in Reason, where I could summon any device with just a few keystrokes. Hammerspoon has a module called chooser which gives you a nice looking search bar from which you can pick one option out of a list you provide to it - perfect for choosing devices. The challenge then is creating and maintaining an accurate list of the available devices, and ranking the search results in a useful way.

Reason lists every device in the Create menu, and Hammerspoon has a module for querying those menus. By recursively scraping the menu options we can build a map of device names to their menu selectors, so when I pick a device in the chooser, Hammerspoon will select its associated menu item and create the device. The accessibility API calls to get the menu items are expensive, so I made the recursive rebuild process run on demand rather than every time the chooser is opened.

Instead of scraping the menus each run, a device cache is stored locally in an SQLite database, which is upserted into on each rebuild. The database also keeps track of device usage frequency, which is used in tandem with the fzy fuzzy string matching algorithm to produce a weighted rank of each device for a given search query. Frequency of use is weighted slightly less than fuzzy matching to produce more consistent search results.

The result is a significantly faster and infinitely more useful device creator that I actually like better than the Ableton feature that inspired it. In fact, I liked it so much that I’ve been building a version for Ableton, using their new extensions API.

Not overdoing it

It’s important that an extension like this doesn’t try to do too much - it should integrate fairly seamlessly into the natural UX of the software. Additionally, if the extension breaks or I use Reason on another computer, I don’t want to feel like my productivity is significantly hampered. This led to me leaving the rack and the mixer mostly alone, with just some simple remaps to keep shortcuts on the left hand.

Conclusion

I’ve been using some version of this extension for a few years now and it’s made a night and day difference in my speed and efficiency with the DAW. Many of the things I originally had in the plugin (such as pinch zoom on the trackpad) were eventually added to the software after I posted about them on various forums - I won’t claim responsibility, but I’ll celebrate being on the right side of history.

I think there’s something to be gleaned from the gamification of creative software - clunky workflow leads to slower creative output, which is frustrating when you’re chasing a fleeting idea. If you treat each hand as an anchor point and build actions around that, the user will feel more connected to the software and the barriers to creation will shrink significantly.

The full code is up on GitHub if you want to try it out.