Mac Support

[ipfaffy]

Deej seems really cool/useful, but I use a mac as my main computer. Are there any plans to get Mac Support on the roadmap?

[omriharel]

Hi there @ipfaffy, thanks for writing!

I looked into this, but it seems that currently there isn't any Core Audio library to allow adjustment of individual app volumes on OSX (and thus, also no Go bindings for one).

The closest thing I found was a cool application called BackgroundMusic, which I haven't delved too much into but it seems to include a driver-like component that registers itself as a virtual audio output device, uses Core Audio to distinguish individual audio streams coming into it from other apps and makes them adjustable through a Cocoa-based tray UI.

Doing the same with Go, while certainly possible, is beyond my capabilities. Unfortunately I don't think Mac support will be added anytime soon :(

Other functionality in deej should be fully cross-platform, so if anyone feels like they can tackle the Core Audio stuff that would be very welcome!

[marcuswu]

I have submitted a PR for adding AppleScript support to BackgroundMusic with the intent of connecting to hardware sliders via a system like deej. Now it should be relatively trivial to interface deej to BackgroundMusic via os/exec to run AppleScript commands.

I need to design and build out my electronics / hardware so it might be a moment before I can write that layer. Perhaps someone else can get to it before me, but if not once I have my hardware set up I'll write something up and submit a PR here.

[omriharel]

Hi @marcuswu, thanks for writing.

This looks like an interesting option, but I would not want to go with it as a core implementation for deej's main fork because it relies on an external piece of software (that I'm not able, or willing, to package with deej). A core implementation would have to use a more native approach, in the interest of debuggability and performance.

That being said, I imagine that if you implement this in your own fork of deej, it would be a completely feasible solution for most folks wanting to run it on a Mac (and I'll be happy to link to that from a resource such as our user FAQ).

[marcuswu]

You listed a few concerns here, what are your criteria?

I believe deej already relies on external software that's not packaged directly with deej. Is it because it's not a go project that can automatically be pulled and managed with go tools? If someone built some go code to add to deej to interact directly with BackgroundMusic's audio driver, would that suffice or are you unwilling to use BackgroundMusic's audio driver either? How much is performance a concern here?

I would like to understand more before I decide how I'll spend my time.

[omriharel]

deej is currently distributed to most users as a standalone binary with no pre-requisites, other than having a connected hardware device to talk to. Every audio-related interaction is done directly against the operating system's audio APIs, and not some external software that the user is required to interact with (or ensure its existence). This is the most critical aspect IMO, and it applies regardless of whether the client code interacts with Background Music via AppleScript, direct communication with its internal audio driver or any other means.

As for performance, it shouldn't necessarily become an issue with your approach - it likely isn't - but it is crucial that calls are able to be executed rapidly (taking very little time to act) and in quick succession - as a potentiometer movement can generate as much as thirty calls (at 3% volume increments). If that isn't the case, interacting with the hardware isn't gonna feel snappy and responsive.

To be fair, I haven't measured out the real performance cost (if any) of doing something like this, but if you were to use something like os/exec every call directly translates to a fork operation - which could absolutely get laggy under some circumstances (especially when e.g. a slider is bound to multiple audio sessions and needs to adjust each one that many times). The only way to know for sure is to test it out in a scripted manner - if it seems fine there, I can't think of a reason it wouldn't work well with deej.

I'm not ruling out the possibility of it being a fully working solution, but it's not necessarily one I'd be comfortable signing off on. I hope that gives the additional context that my previous reply lacked, but if you have additional concerns I'm happy to address them :)

[geekquixotic]

I looked into this, but it seems that currently there isn't any Core Audio library to allow adjustment of individual app volumes on OSX (and thus, also no Go bindings for one).

The closest thing I found was a cool application called BackgroundMusic, which I haven't delved too much into but it seems to include a driver-like component that registers itself as a virtual audio output device, uses Core Audio to distinguish individual audio streams coming into it from other apps and makes them adjustable through a Cocoa-based tray UI.

There is also an application I use by Rogue Amoeba called SoundSource that has the same functionality. They list Shortcuts support on their site which would provide those hooks.

I know it's more than just that, and I don't have the skills to help either; but I like this idea so I wanted to point out another possible way into macOS for you.

[omriharel]

Thanks for pointing this out, @geekquixotic - however, this is still not a native solution and as such wouldn't be able to be completely contained within deej.