Under The Microscope

With Audio Hijack 3.6, Our Software Is Now All Catalina Ready

Apple has just released the first official version of MacOS 10.15 (Catalina), and our software is ready for it. If you haven’t seen our Status page before, it’s certainly worth a look now. As you’ll see, all seven of our major Mac apps now have compatibility with Catalina. If you’re updating to Catalina, make sure you’ve got the latest versions of our apps. Once you do, you should be good to go.

What’s New in Audio Hijack 3.6?

Over the past two months, we’ve had issued over a half-dozen updates to provide Catalina support. However, until today, our flagship audio recorder Audio Hijack had not yet been updated. This update required the most attention and care, and we wanted to be sure it was ready to go before providing it to you.

Thankfully, we completed the necessary work just ahead of Apple’s official release, shipping Audio Hijack 3.6 this morning. This update goes well beyond simply adding support for the new OS. This is just a partial list of improvements you’ll find in the latest Audio Hijack:

Dramatically Improved Device Handling

Like our recent Loopback 2.1 update before it, the tracking and handling of physical input and output devices in Audio Hijack has been greatly improved. Because many popular USB audio devices fail to contain unique identifying information, it has often been necessary to re-select these devices after restarting your Mac or moving the device to a different USB port. Audio Hijack will now automatically track devices across restarts and between ports, so fewer adjustments are necessary.

Support for Dark Mode

Audio Hijack 3 has always had a dark appearance, but it has not previously had support for Dark Mode on MacOS 10.14 (Mojave) and higher. With the latest update, windows throughout the app will properly appear dark if you’re using Dark Mode on your Mac.

Updates to Declick, Dehum, and Denoise

Since Audio Hijack 3.0, we’ve included three built-in plugins to help you clean up common audio issues. The Declick, Dehum, and Denoise plugins bring powerful audio cleanup to anyone. These plugins were previously powered by licensed third-party technology. Unfortunately, that backend technology was no longer usable on modern versions of MacOS. As a result, we’ve overhauled these plugins with our in-house updates. If you’ve previously used these cleanup plugins, you’ll want to experiment anew, and update your settings. If you’ve never used them before, now is a great time to check out Declick, Dehum, and Denoise. For more information, see the “Advanced Blocks” page of the Audio Hijack manual.

An Enhanced Application Source Selector

The Source selector, found in the Application input block, has also been updated and improved. It’s now a snap to capture audio from Finder and Text to Speech, with the new “Special Sources” section of the Source selector. Other minor interface improvements have been made as well, all to make it easier than ever to capture the audio you want.

Bug Fixes and Improvements Galore

There’s much more to be found in Audio Hijack 3.6. We’ve got over two dozen changes and improvements.

More to Come

We’re always working on new features and improvements to our software, and a new OS update often necessitates additional releases to fix rare issues. It’s likely you’ll see further updates for Audio Hijack, as well our other products, in the coming weeks.

You can be sure you’re always running the latest versions of our apps by using the built-in version checking.

Just make sure “Automatically check for updates” is turned on in the app’s Preferences windows, and you’ll be alerted to new versions as they become available. For right now, all of our products should be good to go on Catalina.

Loopback 2.1 Makes Audio Routing Easier Than Ever

Loopback 2.1 is here, and it includes some great enhancements to our powerful audio routing tool. Since its first release, Loopback has given podcasters, audio techs, and many others the power of a high-end studio mixing board, right from software. Now, the application is more refined than ever. Read on for more, or simply update to Loopback 2.1 by selecting “Check for Update” from the Loopback menu!

What’s New in Loopback 2.1?

For this update, we focused on perfecting many different aspects of the application to provide the best user experience yet. Loopback 2.1 includes a whole host of refinements, but it’s also got one very visible change. Let’s start there.

Loopback Goes Dark

The first thing many users will notice is that Loopback now offers an optional new Dark appearance, and it looks great:


Loopback’s new Dark Mode appearance

If you’re using Loopback in a dimly lit studio or other darkened space, this new theme will serve you well. You can adjust the application’s appearance right from the Preferences window. With the default “Match System” setting, Loopback will follow your OS-wide appearance.1 If you prefer, you can force Loopback to use the “Light” or “Dark” theme, regardless of your system-wide settings.

Better Handling of Physical Audio Devices

Loopback’s virtual audio devices can pull audio from both applications and physical input devices like microphones. Unfortunately, many popular USB audio input devices incorrectly fail to contain unique identifying information. As a result, it was often necessary to tweak the settings of your Loopback device to re-select the desired inputs.

That’s all in the past now, however, thanks to improvements made in this release. Loopback now does yeoman’s work to keep track of your devices when they move between ports on your machine, as well as across restarts. With this update, you’ll have far fewer erroneous “Device Missing” errors.

Sometimes a device truly is missing, however, and we’ve improved how Loopback handles this as well. If a physical device isn’t currently connected to your Mac, you’ll see a warning like the image above. The improved indicators for missing inputs and monitors should help you diagnose and fix misconfigurations faster, and with less hassle.

Our hope is that you’ll barely notice these particular changes. Instead, Loopback will just keep things humming along for all your virtual devices.

Catalina, We’re Ready When You Are

Some time next month, Apple will be shipping the latest version of the Mac’s operating system, MacOS 10.15 (Catalina). At present, the release date has only been given as “October”. Fortunately, Loopback 2.1 is already compatible with Catalina, so whenever it arrives, you’ll be ready to go!

And So Much More

There’s a slew of other improvements to be found in Loopback 2.1, from CPU optimizations for our level meters to interface improvements on disabled and selected items. We’re better handling slow monitoring devices, so you don’t miss any audio, and made the app more resilient against breakage previously caused by “cleaner” utilities deleting important files. There’s a new Release Notes window so you can see what’s changed, an overhauled wizard for installing and updating the software, and advancements in our Help system. Heck, we even improved the About box to better show your current version information!

Loopback 2.1 is our best release yet, and we can’t wait for you to try it out.

Get Loopback 2.1 Today

Thousands of podcasters, live streamers, and audio techs swear by Loopback. Virtual audio devices give you control over how audio flows on your Mac, making it possible to do incredible things. If you’re already a Loopback 2 user, just select “Check for Update” from the Loopback menu to move up to version 2.1, or click “Free Download” below to download it directly.

If you’re new to Loopback, visit the product page to learn all about our powerful audio routing tool.

Loopback 2.1 works on MacOS 10.12 and higher. Our free, fully-functional trial allows you to explore all that Loopback offers, after which you can purchase through our online store for $99.

Helpful Loopback Links



Footnotes:

  1. The “Match System” option follows the General System Preference. On MacOS 10.14 and up, it follows the “Appearance” setting, while MacOS 10.13 and 10.12 use the older “Use dark menu bar and Dock” setting. ↩︎

The Finder Really Should Prevent Moving Running Applications

Yesterday, I wrote about how our software works to avoid issues if the application is moved while its in use. We shared some code for this which could be useful to other Mac developers, and Daniel Jalkut produced a more robust drop-in, which all Mac developers should check out.

Our products have handled this issue well enough for many years, and we were generally content with our solution. However, due to changes made in MacOS 10.15 (Catalina), we recently had to dumb down our approach. For years we used GCD (dispatch) to observe the application’s folder, as well as parent folders, to see if they moved. This doesn’t work very well on Catalina, where if the application is residing in the Downloads folder, the OS thinks the user needs to be warned we are “accessing” the Downloads area. To avoid frightening users with unnecessary security dialogs, our solution is now less robust than it once was.

After discussing all of this with Daniel, we came to the realization that this really isn’t something individual developers ought to need to handle at all. Instead, it makes the most sense for Apple to help users avoid this issue at the Finder level.

As much as one might want to move a running application, Apple’s Cocoa framework is simply is unable to correctly handle the situation at present. This leads to unexpected application behaviors and even crashes. To avoid these issues, the Finder already works to avoid multiple types of changes to running applications. For instance, if you try to delete an application that’s open, the Finder stops you:

As well, if you attempt to rename an open application, the Finder will warn against it:

This dialog allows you to proceed with the rename (and even makes that action the default), but it at least provides a warning that this action is not be advisable.

However, while any Unix geek can tell you that a rename is really just a move by another name, the Finder does nothing to stop you from actually moving the app. This seems like a real oversight, and something that can and should be fixed on Apple’s end.

I opted to file a bug with Apple about this (#FB7216674). Perhaps developers will one day see the Finder handling this for us.

Avoiding Crashes Caused by Application Moves

One of the best RSS readers on the Mac, NetNewsWire, has returned home to its original developer Brent Simmons. Late last month, Brent and his team of volunteers shipped version 5, and I’m delighted to see the return of NetNewsWire on the Mac.

Along with the release, Brent has been posting frequently to his blog at inessential.com. While discussing a piece he’d published on post-release follow-through, Brent noted “I keep remembering that I know things that I figure everyone knows — but then I remember that they don’t. So I write ’em up”.

This is a noble practice, and it’s inspired our own post, where we’ll be sharing some information and code.

Avoiding Crashes Due to Moved Applications

Following the release of NetNewsWire 5.0.0, Brent discovered the application had a crashing bug. Working with Daniel Jalkut of Red Sweater, they determined that the problem occurred when the application was moved in the Finder. When I saw Brent’s post detailing this issue, I knew we could help.

For many years, Rogue Amoeba’s applications have guarded against this very issue. If one of our applications is moved while it’s running, it will display an error like this:

This alert lets the user know they’re likely to run into issues, and urges them to quit and relaunch.1

Sample Code and Details

I discussed this issue with Daniel and Brent, and provided them with the code we’d been using to watch for this issue. This actually led us to make several changes and tweaks, and a simplified implementation of this “Application Moved” watcher can be found below:

- (void)_showBundleMovedAlertIfNeeded
{
    //This depends on bundleURL being cached and not updated when the app moves
    //Perhaps someday that will be false, but it's true now - 2019-09


    if( [[[NSBundle mainBundle] bundleURL] checkResourceIsReachableAndReturnError: nil] )
        return;

    NSString *appname = [[NSProcessInfo processInfo] processName];
    NSString *messageFmt = @"%@ has been moved or renamed";
    NSString *infoFmt = @"To prevent errors, %@ must be relaunched.\n\nIf you cannot quit immediately, click Continue, then quit and relaunch as soon as possible to avoid problems.";

    NSAlert *alert = [[NSAlert alloc] init];
    [alert setAlertStyle:NSAlertStyleCritical];
    [alert setMessageText:[NSString stringWithFormat:messageFmt, appname]];
    [alert setInformativeText:[NSString stringWithFormat:infoFmt, appname]];
    [alert addButtonWithTitle:@"Quit"];
    [alert addButtonWithTitle:@"Continue (Not Recommended)"];
    
    NSInteger alertButton = [alert runModal];
    [alert release];
    
    if (alertButton == NSAlertFirstButtonReturn)
        [NSApp terminate: self];
}

- (void)applicationDidBecomeActive:(NSNotification *)notification
{
    [self _showBundleMovedAlertIfNeeded];
}

This code was inspired by changes from Daniel, as well as Rich Siegel of Bare Bones. Whenever the application becomes active, we look if the bundle still exists where it should be, and throw an alert if not. This implementation is by no means perfect. For instance, if the application is moved and not activated for awhile, it could fail to notify the user before a problem hits. On the other hand, it gracefully handles other difficult edge cases, like the parent folder of the application being moved.

This is part of the shared code we use in all our applications, so improving it in one place will benefit all of our products. It’s good to revisit and refine things over time, and sharing this code with others has provided us with a nice opportunity to do so.

Closing

If you’re a Mac developer, you might have just realized why some previously inexplicable crashes have been occurring. With the above, you’re well on your way to handling the issue and avoiding crashes.

Over nearly 17 years of developing software for the Mac, we’ve created a lot of useful internal systems and generated a great deal of institutional knowledge. It’s good to be reminded that this accumulated knowledge can help other developers too. We’ll be keeping an eye out for more things we might share with other Mac developers.


Footnotes:

  1. It’s likely that most applications should simply force the user to quit, but as you can see, we also provide a “Continue” option. For our applications, the user may be in the middle of an important and uninterruptible task, like making a recording, so we don’t want to force them to quit the application. ↩︎

Hear All About Us: SoundSource’s Honors and More

A Rave Review for SoundSource

2019 has featured major updates to our sound control utility SoundSource, with version 4.0 shipping at the end of March, and a major update to version 4.1 two months later. These updates have been met with much acclaim, and now Macworld has named SoundSource an “Editor’s Choice”, as part of a near-perfect 4.5/5 mice review.

If you haven’t checked out SoundSource yet, now’s a great time to see the app Macworld calls “a must-have utility”.

Company Profile

I recently took part in an in-depth interview about our products and our history with the folks at HostingAdvice. The result is a fine profile of our company, which touches on both our software products and our philosophy about software development in general. Click to give it a read.

The Mac Quadcast

Finally, I also recently spoke with Darren Carr on his show “The Mac Quadcast”. We discussed my own background, Rogue Amoeba’s work, and the amazing “Voice Control” system coming to Apple’s devices. Check out episode #24 of the Mac Quadcast right here.

Our Software