Cabbage Logo
Back to Cabbage Site

Need help exporting plugins to MacOS

Hopefully this is acceptable to ask, but I can ask someplace else and remove this topic if not.

I don’t own any Apple products, and I would like to release two new plugins with support for MacOS. I planned to get a dedicated Mac device of some sort just for this, but I don’t have the financial means right now, as I’m stuck funding my university education.

Could anyone, with the time and willing energy, export an AU plugin and/or a VST3 plugin on their Mac device of the two Cabbage plugin ZIPs below and post it here? They’ll be included with my Windows and Linux releases on their GitHub pages, and I am willing to provide credits, links, or negotiate anything else to get these plugin formats. I don’t mind automating the plugin exports with a GitHub Actions script if that is ready and available.

Here are the two ZIPs. Thank you in advance to anyone who decides to help: StepRouter.zip (23.0 KB) SaladSlicer.zip (28.6 KB)

Hi @circuitdust,

I worked on an Azure Pipeline script that can do it, so it’s something I can help you with if needed.

There are two things that could block you:

  • You need to codesign your plugins, otherwise it won’t run on other machines. For that, you’ll need an Apple Developer Program subscription and I think you have to get the certificate on a MacOS machine…
  • You need to notarize the installer so it doesn’t raise security warnings when users install your VST. I think it is not mandatory but it improves the user experience imo.

Maybe you could try to get a cheap old MacBook/Air/Pro? You might find one for less than 300-400$.

Once you find a way to get a certificate I’m happy to help you set up an automated way to generate the vst in Azure, codesign it, create an installer, and notarize it.

1 Like

The Apple tax is the worst part, but if you want to distribute plugins for Mac you have to pay up. What’s really galling is you have to pay it even if you distribute your software for free.

1 Like

Wow, $99 to sign code, that seriously blows. Will I need to notarize anything if I plan to simply distribute the binaries for manual installation? I don’t want to deal with installers really.

Would getting an old Mac or MacBook affect the exporting of the plugins between chipsets? I just know that there are nuances in ARM-compatible and Intel versions of MacOS VSTs or AUs, or something along those lines. I could work with that if Cabbage isn’t affected and get something around $100 - I’m just not ready to get a used M1 MacBook Air as they’re still pricey and I would wait a month or so before committing to that investment.

Edit: I was also looking into running MacOS in a VM but it would again require a device to export the OS image if I was to do it legally.

It sure does.

I can’t really say. It should be but you’ll need to test it. It’s also possible for you to ask your users to codesign the plugins themselves using adhoc codesigning - but this will only work for some hosts. Live and a few others will not load plugins that aren’t codesigned. But Reaper loads them fine. You could distribute a simple bash script with your plugins that will do the adhoc signing for end users. Things on Windows are better for the moment, but I fear they will push their signing certs more and more in the next few years and we will be in a similar situation there.

1 Like

Based on my understanding, you can use older architectures (Intel ones) and export ARM compatible VSTs with Cabbage. Until recently I used Cabbage on an Intel 2018 MBP and my friends on ARMs architectures had no issues. (@rorywalsh please correct if I’m wrong!)

The codesigning process sucks, and is expensive. I automated it, but it’s a pain…
If you’re a student can you check if your university has a partnership with Apple and if you can get it for free?

If you want to distribute presets (and create the presets folder in the Music/ directory for example) I think it’s more convenient for the user to build an installer. FYI you can automate the process with packagebuild and once it’s done it’s just a command line to run on your end to generate the pkg.

Maybe that’s a crazy idea, but do you think the codesigning could be bypassed by adding this ad-hoc signing in the installer? It’s definitely hacky but maybe it would work :joy:

1 Like

Sounds good. I’m getting my hands on a used 2015 MacBook Pro, so hopefully I don’t get complaints from ARM folk down the line that my esoteric plugins aren’t working for them :joy:

Unfortunately not, at least not for the typical student. The least that Apple does is have some authorized repair center but it is subpar from what I heard, haha.

I will hold off on paying for the license until I happen to make another plugin, as I got a generous volunteer to export these for me (edit: not sure if they codesigned, will have to check), but I am still interested in having the automation script. Is there a particular reason why it’s through Azure, or would it be possible to transcribe it into a GitHub Actions script?

I have presets but they are held in the same directory as the plugin. It works for now, but I will look into installers if I need to in the future.

How would this script work, are there any examples? Definitely seems worth doing.

This is one I use to adhoc sign my plugins. It takes one parameter: a path to the plugin bundle.
adhoc.sh (55 Bytes)

1 Like