SuperMegaUltraGroovy Blog

Capo 4.7 is Here

2026-06-04T10:00:00-04:00

Today I am pleased to share that Capo 4.7 is now available:

Get Capo 4.7 for macOS on the App Store
Get Capo 4.7 for iOS on the App Store

Lead Sheets

The biggest feature of this release is exclusive to the Mac. Capo can now produce publication-quality printouts or PDF files using the chords and sections that you set up in the project.

You can try this out today if you have an active subscription. Just choose File > Print… from the main menu once your song is ready to go. Then, add a title and subheadings, decide whether you want to include the chord vocabulary, and the rest works just like any other Mac app.

Call & Response Mode

Inspired by my research, Capo now provides a new way to play your looping regions: alternating between the recording, and playing quietly. To enable this mode, you long-press on the loop button while a region is selected. You can also make the quiet part play as loudly as 50% of the original volume, in case you find that helpful.

This mode is helpful in a number of ways:

If you just listen in this mode, you can use the (totally) quiet period as an opportunity to hear it again in your head. This musical imagery exercise helps you build your memory of the melody/solo that you're trying to copy from the recording.
While practicing, you can test your sense of time against the original. If you can play the notes yourself during the quiet period, you know you are able to play it at the current tempo.
When you play the part yourself during the quiet period, you're comparing what you hear against your memory rather than the recording—this is much less distracting than trying to listen for the recording at the same time you're listening to your own playing.
On the Mac, you can use this mode in the Tabbing song view to confirm your note entries. The Call & Response settings let you configure the note entries to play during the quiet period so that you can confirm your entries against your memory of the notes you're trying to copy.

I wrote a bit more about this in my last blog post, where you can learn more about the rationale behind this feature.

I've been playing with this new mode for the past few weeks while testing the update, and I think you're going to love how well it works.

Fixes and Improvements

There is a lot of stuff that goes into the "miscellaneous bin" for this update. Some of these are fixes for issues I found while building the new features, and some can be tied directly to user feedback that I received during the same time. I'm always thankful to those of you who reach out to let me know about the sharp edges that need attention.

You can learn more about what changed by reading the What's New pages for each platform:

User Guide Changes

One big item on this list is a totally new User Guide that now covers both platforms in the same place. But it's also searchable, and I'm trying to be mindful about where I put different kinds of content.¹

I really wanted the user guide to be "more finished" than it is right now, but I really needed to get this release out the door before WWDC hijacks all my focus for a week or so. I'm going to keep plugging away at it, and I would like to hear your feedback about the guide.

In case you also write documentation, or you are curious about the process, I'm trying to follow the Diàtaxis framework. This seems to have caught on mostly for API documentation, but I find it is helpful to know where different kinds of content should live. ↩

Call & Response Mode: Coming Soon

2026-04-24T14:05:00-04:00

My research uncovered a few ways that software could support musicians' interactions with recordings. Some of my findings pointed at features Capo already had, but I didn't recognize their importance when they shipped. For example, I recommended that software should allow musicians to easily trigger the playback of a few notes at a time—Capo's Transcription Playhead already offers that interaction. I also suggested that supports should be in place for musicians who can't whistle or remember notes while hunting on their instrument, and the Audio Freezer helps with that. These features were footnotes in their respective releases, but now I consider them foundational tools.

In the next Capo update, you'll get the first feature that I originally proposed in my research: Call & Response Mode. When enabled, Capo alternates between playing the original recording and quiet¹ while a region is looping. This feature has three main benefits: (1) it primes your memory for learning, (2) helps you judge your own playing better, and (3) reveals the target notes in a dense mix.

Using the Transcription Playhead, you'll find notes more quickly if you don't have to keep consulting the recording over and over again. Ideally, you want the notes in your mind, with the recording handy to refresh your memory. Before Call & Response mode, you'd place a region around a bar or two of the solo, and hear it over and over again. But that won't work, because memories are made stronger each time we retrieve them. During the quiet period of a Call & Response loop, you'll start to "hear" that music playing in your mind. Whistle or sing, and the memory gets even stronger. After you've "primed" your memory, it gets easier to work through the solo with a copy of the music etched into your mind.

Once you have the notes under your fingers, it's time to practice with looping regions. Unfortunately, without Call & Response mode, this is taxing for your brain—when you play along with the recording, you have two streams of sound to process at once. Are you comparing your playing against the recording, or your memory of the recording? And if you're trying to listen to the recording, you'll play quieter and out of time until you hear it better. But with Call & Response mode, the recording refreshes your memory, and you use the quiet period to compare your playing against the notes in your mind. Rinse, and repeat. Again, when you work from memory, those connections get stronger in your mind. Judging your playing without the recording is going to help you develop a critical ear for what sounds right.

If you're working with a recording that has too much going on, you might be tempted to reach for a "stem splitter" in hopes that AI is going to make those notes easier to hear. But your musical heroes did this long before AI existed, and those tools aren't always going to work. If you're on a Mac, there's a novel way to use your (very capable) brain and ears to locate the right notes with the Tabbing song view and Call & Response mode. Draw out the notes on the spectrogram to match what you're hearing, and playback alternates between the recording and your note entries.² Listen carefully to those notes in the recording, then compare Capo's note entry playback with your memory of the music—make adjustments while the recording plays until you get them right. Here you're trying to interpret what you hear in the recording, which is a key part of learning by ear. You're judging what sounds correct, and your brain is really good at telling you when you don't quite have it yet.

So that's Call & Response mode, useful in three ways: priming your memory of the recording before you learn from it, getting out of your way while you practice, and helping you find notes in dense recordings. With features like these, Capo continues to grow as a tool that helps your brain do what it does best while learning by ear.

The "quiet period" can play anywhere between 0 and 50% of the original volume. ↩
If you're using an iPhone or iPad, you can also do this by singing, humming, or whistling the notes. You'll be relying more on your memory and skills here, but you're also building them up while you do this. Try it out! ↩

Capo's Own Language

2026-04-08T15:32:00-04:00

Just before I started grad school in 2022, I began picking away at the "Keyboard and MIDI Overhaul" project that was meant to improve Capo's support for MIDI controls and extend them to iOS. It was an ambitious project, and it ultimately spawned a little domain-specific language (DSL) for configuration.

Keyboard and MIDI controls are "power-user" features, and a combination of configuration files and documentation seems like a good power-user interface. But even power users are unlikely to know what specific messages their MIDI hardware spits out, and users on iOS would have a harder time writing and editing code. So I committed to building a comprehensive UI to configure keyboard and MIDI bindings in Capo. The DSL is still there, but it's used entirely behind the scenes.

The .caporemote configuration file contains a list of bindings, and each binding consists of a trigger that executes one or more commands. Here is a simple example of a keyboard binding:

keyDown(rightArrow) {
  goToNextEntry(in: bars)
}

This language is easy to read: when you press the right arrow key, Capo will go to the next bar entry. Even complex bindings remain quite readable:

controlChange(channel: 2, number: 16, value: $value) {
  setSpeed(to: $value[25:100])
}

This one triggers when Capo receives MIDI Control Change (CC) #16 messages on channel 2, and it passes the current $value to setSpeed(to:). The numbers in the square brackets define the output range: we only want values between 25% and 100%.

Compared to an XML, JSON, or YAML configuration file, this DSL isn't just easy to read—its parser can also tell you when something's wrong. For example, writing goToNextEntry(in: potato) produces an error pointing at the exact line and column, along with the expected values: bars, beats, or markers. By contrast, an XML, JSON, or YAML parser would happily accept it, leaving the user to hunt for their mistake without guidance.

I built my DSL's parser using the swift-parsing library from Point-Free. In addition to parsing, this library lets you build a Printer so that you can work in reverse. In my case, this is how the configuration gets saved to disk.¹

The parsers themselves use ResultBuilder syntax. Here's a modified version of the command parser:

public struct CommandParser: ParserPrinter {
  public var body: some ParserPrinter<Substring.UTF8View, CapoRemoteCommandDescriptor> {
    OneOf {
      // ... skipped
      
      Command(
        name: "goToNextEntry", 
        converter: .case(CapoRemoteCommandDescriptor.goToNextEntry)
      ) {
        ConstantParameter<CapoRemoteCommandDescriptor.NavigableEntry>(name: "in")
      }
      
      Command(
        name: "setSpeed", 
        converter: .case(CapoRemoteCommandDescriptor.setSpeed)
      ) {
        PercentageParameter(name: "to")
      }
      
      // ... skipped
    }
  }
}

It's not important what each Command parser does, or why it takes a converter: parameter—those are boring implementation details. Instead, I want you to recognize the simplicity of this overall structure: it parses (and prints) OneOf these named Commands. The goToNextEntry command takes a named ConstantParameter of type NavigableEntry, and the setSpeed command takes a named PercentageParameter.

This CommandParser composes a collection of smaller, focused Command parsers to form the larger one. Adding a new command to Capo means adding a new Command parser to the list above.

Parsing was the easy part. The harder problem was designing the system that consumes those parsed values. First, I had to catalog every action in Capo worth exposing to a binding—that took a while. Later, I realized I needed two types for this to work.

Incoming MIDI values arrive as integers from 0–127, but the command they trigger often wants something else—a speed between 25% and 100%, say. CapoRemoteCommandDescriptor is the "recipe" that bridges the two: it describes how to produce a CapoRemoteCommand from whatever value comes in. The variable-speed example above produces a descriptor of .setSpeed(to: .variable(.percentageInRange(25...100))), which then emits commands like .setSpeed(percent: 25) or .setSpeed(percent: 30) as MIDI values stream in. For simpler bindings the two types look nearly identical—.goToNextEntry(in: .bars) vs. .goToNext(.bar)—and without variable support, having two types would just be duplication.

This was a challenging project, and I'm proud of the result. I'm also disappointed that all this work on the DSL got hidden behind the scenes—I had a grand vision of a bespoke code editor with inline error reporting, and nifty tools for learning MIDI messages. But I had to be realistic about my strengths and weaknesses—text editing and syntax highlighting are not in my wheelhouse. So I'll settle for a pat on the back for spotting that rabbit hole and stepping around it.

This piece was inspired by this month's Swift Blog Carnival on Tiny Languages. I've been trying to write more on this space lately, and this month's prompt gave me an excuse to think and write about my work on this project. Thanks for the nudge, Christian!

If you're using Capo already, you can take a look at ~/Library/Containers/com.supermegaultragroovy.capo3.mac/Data/Library/Application Support/commands.caporemote to see this in action. ↩

My Overdue Eulogy for the Mac Pro

2026-03-27T15:25:00-04:00

The Mac Pro is now officially dead—but it's been dead to me for years.

I ordered my first quad-core Mac Pro in early 2008, and later got an 8-core 2013 Mac Pro.¹ These two Macs helped me bootstrap the OpenCL spectrogram kernel that put Capo on the map.

During the "dark period", while we all waited for the follow-up to the trashcan Mac², I decided to go hard when I configured my iMac Pro: 18 cores, 64GB RAM, and a Vega 64 GPU. With this Mac (and the help of two eGPUs) I developed and trained the neural network that powers Capo's world-class chord detection engine.

I was nervous about splashing out on the iMac Pro, because we were promised that something big was coming soon. But the polished-stainless-steel Mac that Apple introduced in 2019 was…clearly not for me. Instead, it was aimed squarely at movie and music production environments: with multi-GPU upgrade options for 3D work, video codec accelerators, PCIe slots for wacky audio gear. They even offered a rackmount option to complete a tidy installation in the million-dollar studios they were meant for.³

I think Apple would have been wise to call that product the "Mac Studio", but I digress…

For me, the death of the Mac Pro as a viable development system started around 2013. It wasn't about upgrades or GPUs. It was simpler than that: I felt like one of very few suckers who bought my specific configuration, and nobody at Apple actually used a similar machine. For example, my 2013 Mac Pro had AMD FirePro D700 GPUs (a rare configuration) that often had issues with graphics corruption. Later, my iMac Pro—with its 18 cores—gave me all sorts of trouble in Xcode, often compiling Capo more slowly than my 2013 Mac Pro could.⁴ Adding insult to injury, these machines were not cheap! I tried to "throw money at the problem (of making big computations go faster)", but I actually just bought headaches.

My own software pushed these machines to their limits. Final Cut Pro and Logic ran great too. But Xcode—the thing I use most every day—was a mess.

Anyway, from 2008–2022 I was living the two-Mac lifestyle: a powerful desktop for the heavy development, and a MacBook Pro for work outside the office. And you know what? Those machines didn't just work, they worked great: excellent displays, and they were getting pretty fast—especially after they moved to SSD storage.⁵

But do you know what still sucked about these portable Macs? The desktop experience. You plugged it into a power adapter, and then a second cable for the screen. And that was a crapshoot: weird delays, maybe the wrong resolution (with third-party displays), the keyboard didn't wake the Mac, and sometimes you just had to unplug and try again. It was so frustrating! So I still clung to my dreams of a "Professional Desktop Mac", hoping for a better solution.

Finally, in March 2022 I got my 14-inch MacBook Pro with an M1 Max and 64GB RAM. This machine absolutely ripped apart my iMac Pro—it even trained Capo's custom neural network faster than my Radeon 7 eGPU! But it wasn't until later that summer, when I got a Studio Display, that I got to experience my new favorite "Professional Desktop Mac".

In the morning, my MacBook Pro went into my backpack, I dropped my kids off at school, and went to my office at the University.⁶ I did my schoolwork, attended classes, and worked on my thesis. In the afternoon, I returned to my home office and—after attaching a single cable to my Mac—I was right back where I left off. There were no delays, no fiddling. Everything Just Worked™.

Four years later, and it's still my daily driver. Sometimes when I'm "done for the day", I'll unplug the Mac from the Studio Display and bring it up to the living room. I might check in with support after dinner, or tackle short development tasks from my couch. Some days I'll start work from that spot, because it gets cold in my basement office. When I need more screen space, I head down to the office, and boom: one plug, right back where I left off.

This is something that the Mac Pro could never do: pause the work at my desk in whatever state I left it, resume it from a completely different location—in a library, a coffee shop, or waiting for my car to be serviced—and then cap off the work back at home. And the best part is that this all happens with almost no compromise in performance, and no "range anxiety" that has me carrying a charger.

For me, this "Professional Desktop Mac" experience is nearly perfect⁷, and I haven't looked back at those days of heavy, expensive, power-hungry, heat-generating desk ornaments with anything but disdain. Good riddance, I say!

I also had a PowerMac G4 with the mirrored drive doors in 2004, but we're talking about the Mac Pro, so… ↩
I always disliked the "trashcan" nickname because I absolutely loved the design of the machine: it wasn't trash at all! ↩
And yes, you could also buy wheels! ↩
Capo would often take more than 8 minutes to compile on the iMac Pro, with the CPU sitting idle for most of that time. Things eventually improved, but it took years. ↩
OK, so it wasn't all good: the keyboards got really, really bad for a while there. But I think that I only ever owned one butterfly machine: the late 2016 MacBook Pro with the Touch Bar, which I thoroughly enjoyed using, and gave my 2013 Mac Pro a run for its money. ↩
I was in grad school during that time, and it feels like forever ago. ↩
They were so close, but they really soured the experience with the Studio Display camera. The one in the iMac Pro was incredible, and this one is garbage. I'm sure the updated 2026 model is better, but I don't take enough video calls to justify the expense. ↩

Printing in Capo: Should be Easy, Right?

2026-03-06T15:06:00-05:00

I cannot express how big of a deal it is for Capo to let users print chords. It is easily the most-requested feature.

Fortunately for my users, I am not one of those people that says "printed charts are silly" and ignores the feedback. Heck, I bought a binding machine and printed most of the research papers I read during grad school. But unfortunately for my users, I care a lot about quality printouts, and I want to get this right. So that's partly why it's taken so long for me to make progress on this.

What my users often ask for is a printout of the Chords Song View—they can see the chords, so just put that on paper. But that would actually be disappointing: chords would get cut in half across pages, and the paper would be filled with lots of wasted space.

And even if I wanted to do exactly what the users asked, I hit some snags along the way that made it impossible: mixed SwiftUI and AppKit drawing cannot be printed to a PDF context. Fortunately, this technical limitation forced me to work on a new chord layout and rendering pipeline just for printing, and now I have some flexibility in how I approach this.

I have a really bold vision for Capo's printed output, and while I might not achieve everything on my wish list in the first iteration, I think that I can produce something that will please the people who requested the feature. Sure, it's not the full vision. But it's useful, and it's a realistic goal.

It will still be a little while until this is ready to see the light of day, but I feel so much closer than I ever did before.

The SuperMegaUltraGroovy Newsletter is Back!

2025-10-15T10:05:00-04:00

The recent loss of access to my Campaign Monitor account was quite the fire-under-my-ass wake-up call that I needed to revive the SuperMegaUltraGroovy Newsletter. After I spent some time taking it on the chin, waiting for my inner critic¹ to end his tirade, I buckled down and got to work trying to rebuild this project from the ground up.

Why this matters

The newsletter really serves no purpose other than to keep customers informed about what's going on with the company (and to a much lesser extent, me). I originally created the newsletter because social media hasn't worked properly for years². And while this blog serves a very similar purpose, it's more of an information firehose³ where posts will vary wildly in quality and content. I don't expect most of my customers to read this on a regular basis, nor would I ask them to check in regularly or install an RSS reader to keep up.

The SMUG newsletter is a narrowly focused "social media feed" for people who use Capo.⁴ I think that people enjoyed reading the little notes I dropped to them, and on more than one occasion I was thanked for the tips and other information that we shared.

So I think it was worth rebooting, and I didn't mind spending the last few recovering my content from the newsletters still hosted on Campaign Monitor. It gave me an excuse to clean up the Middleman project that we used to use to generate the newsletters in the beginning.

How You Can Help

This is a big ask, but if you or anybody that you know happens to have been a subscriber in the past, please sign up for the list at the newsletter page. I'm re-building the list from nothing, and I will happily take every subscriber I can get.

If signing up for another e-mail newsletter isn't your thing, I totally get it. At the very least, maybe just head over and read Newsletter #015 to see the fruit of my labor.

As if this wasn't painful enough, my mind really wanted to let me me how badly I had screwed this up by neglecting the project for so long. I don't want to jinx it, but I've been a bit better recently about handling this stuff. My inner critic can scream at me all it wants, but nobody said I had to listen to the vitriol. ↩
Don't believe me? Go to Facebook, Instagram, etc., and count the number of items in your feed that come from your friends, family, or legitimate interests. Then, compare that to the number of "promoted" posts from things you could care less about. ↩
In theory, anyway. I haven't been doing a good job with that the past few years, but look at me now—three posts in the span of a week! Manic episode? Hopefully not! ↩
…and maybe other products I have in the pipeline? Don't hold your breath! I have five lifetimes worth of work to do on Capo. ↩