Mac OS Installer

[michaelwillis]

This modifies the .github/workflows/build.yml such that it will build an installer package for Mac OS.

The problem with distributing an audio plugin as a disk image (like the sfizz-1.2.0-macos.dmg found in the latest sfizz release) is that in Mac OS 10.15 and later there is no convenient way to mark the plugin as trusted code, so the operating system refuses to let a DAW load the plugin.

With an installer package, you can right click the .pkg file, select Open, and the operating system shows a dialog warning that the developer cannot be verified. It gives an option to open the installer anyway. After using this method to install a plugin, the operating system will allow a DAW to load the plugin.

After I started working on this, I noticed that there are three different CI configurations: github workflows, appveyor, and travis. Is there a preferred CI solution?

This addresses issue #93

[jpcima]

This seems like a great contribution. Given that I don't have experience with MacOS package installers, allow me to ask: does this have the possibility to install a plugin in the user's home folder?

After I started working on this, I noticed that there are three different CI configurations: github workflows, appveyor, and travis. Is there a preferred CI solution?

The preferred solution would be workflows. Given that github supports macOS well now, there is not a reason to not migrate it along with the other ones. The signing process might be a little delicate, and we'd have also to migrate the secrets.

[michaelwillis]

Given that I don't have experience with MacOS package installers, allow me to ask: does this have the possibility to install a plugin in the user's home folder?

@jpcima Yes, there is a way to do that. I would have to modify the package.xml to support installing in the user's home folder. This is my first time working on a MacOS installer, so I'm still learning how to do this.

[falkTX]

The setup is based on the DPF one, and for DPF I purposefully made it only install system wide.
Main reason is that then it becomes possible to install the same plugin in both user and system dirs.

These macOS installer packages do not automatically create an uninstaller, so user has to remember where/how it was installed last time and match it again. Otherwise there ends up being 2 versions of the same plugins installed.

[michaelwillis]

@paulfd, do you have any opinions about this?

[MTornPDX]

I've been having all kinds of trouble getting my post 10.15 Mac to accept Sfizz installs (and even more trouble getting Logic Pro to accept the plugin), so any improvement on this would bee hugely helpful.

Is the new Mac installer version already up and running?

[michaelwillis]

@MTornPDX I have the new Mac installer working on my machine, but it's not available for until a new release is made that includes this pull request, or you build it yourself.

[MTornPDX]

Gotcha!
I have no idea how to build anything, so I'll just keep my eye open for a new release to come out.

[michaelwillis]

Gotcha! I have no idea how to build anything, so I'll just keep my eye open for a new release to come out.

@MTornPDX Actually, you can get it from my forked repo here:

https://github.com/michaelwillis/sfizz/releases/tag/v1.2.0-macos-installer

Please note that this is not an official release from the sfizz maintainers, but it would actually help for you to try it and let us know in this conversation how well it works for you.

[paulfd]

@paulfd, do you have any opinions about this?

Thanks a lot for the PR first! I agree with @jpcima : moving everything to github is much preferred. Travis was already unused so I guess we can also remove appveyor now. For the system-wide vs user install, given what @falkTX said, I wonder if hiding the config and just installing system-wide is less error prone. I wonder how many multi-user mac configs would want separate plugins and/or plugins versions, particularly for an open-source plugin.

[michaelwillis]

I wonder if hiding the config and just installing system-wide is less error prone.

That's how the installer behaves as built by this PR: it skips the prompt of where to install the plugins, and uses the default system-wide location.

[MTornPDX]

@MTornPDX I have the new Mac installer working on my machine, but it's not available for until a new release is made that includes this pull request, or you build it yourself.

Thanks! I gave that a try. A few notes:

I agree that installing the plugins system-wide without asking is preferable.

I did the "open and override the warnings" trick to install the package, and it worked. But surely Sfizz needs to be signed (or whatever it's called) for Macs, so we don't have to do this? The override process feels a bit sketchy, and would scare away a lot of potential users.

The au version installed in the correct place, but in a folder named "Component". It should be "Components" (note the S at the end), otherwise Logic Pro doesn't see it, and it doesn't get to hang out in the folder with all its other AU friends.

Other than that, all other recent issues still remain (separate from installer stuff, I know) - it ignores all controllers in the VST3, Studio One reads the VST3 as TWO separate plugins (I checked that there were zero Sfizz installed before I did the re-install), and the version number on the AU is all wonky.

[MTornPDX]

(I know it's the wrong topic, but I'm adding this to my previous post for completeness sake)

A bit more about my general recent issues:

I checked the VST3 in Ableton and Bitwig, and the controller issue does NOT show up there. So irritatingly it's a Studio One only thing. Bizarrely it doesn't respond to any controller, even the on-screen volume and pan in the Sfizz plugin!

The double entry problem DOES also show up in Ableton and Bitwig.

Also, the VST3 and AU versions display as from different vendors. VST3 - "Paul Ferrand", AU - "Sfzt".

[paulfd]

I did the "open and override the warnings" trick to install the package, and it worked. But surely Sfizz needs to be signed (or whatever it's called) for Macs, so we don't have to do this? The override process feels a bit sketchy, and would scare away a lot of potential users.

The "issue" is that it requires a 100 EUR / year fee just to notarize the releases, which by itself adds absolutely 0 security to the end user since I very much doubt Apple will double check sfizz's code on any regular basis. So by creating these big scary messages, they create a sense of fear in users and require you to pay them to lift the fear they created on purpose. This has a name: it's called extortion. I'm not sure I want to fold on this, especially given that this is not a commercial endeavour.