Provide installer

[tillt]

macOS installer (dmg or pkg)

• creates the named MIDI port
• configures Synthesia for making use of that MIDI port for light guide control
  • is that even doable? can we safely patch Synthesia's configuration?

[tillt]

Seems that the PKG support for scripting is there but not well documented. Apparently Apple stopped supporting that approach with the advent of their AppStore. The widely recommended way of making sure an application has its setup done / is doing it in the application itself. That's how this will possibly pan out then....

[tillt]

Added a basic DMG but that isnt what I really had in mind when saying "installer". We still need something that does the heavy lifting of that MIDI port setup as well as the Synthesia configuration.

[theartwork]

HI! Thanks for awesome work! With an proper installer maybe it could be a better experience, but it works just fine with xcode project - finally can throw away printed numbers for the keys XD

[tillt]

For the Synthesia configuration;

We would need to assert this OutputDevice in ~/Library/Application Support/Synthesia/multiDevice.xml

<?xml version="1.0"?>
<DeviceInfoList version="1" useSoftwareInput="1">
    <OutputDevice version="1" name="IAC Driver LoopBe" enabled="1" userNotes="0" backgroundNotes="0" metronome="0" percussion="0" lightChannel="-2" />
</DeviceInfoList>

Lets see how gatekeeper likes us patching that file.

[tillt]

Added a Synthesia configuration patch mechanism that works but is not perfectly user-friendly. The user has to accept patching the file in question in a file-dialog. But that seems to work fine then for me - see https://github.com/tillt/KompleteSynthesia/tree/till/0.30

[tillt]

I played a bit with the idea of providing a setup-dialog for giving users a neat and unified way for granting privacy related permissions. The inspiration came from looking at Alfred's permissions setup dialog.

Initially I was hoping I could get the current status of those permissions from macOS and then give users a way to add the missing permissions through a simple dialog. Trouble is, that is broken in macOS - one can not get the status of Accessibility permissions and then hope for achieving anything around Input Monitoring. See https://openradar.appspot.com/7381305

Next approach I tested was ignoring current permissions and simply giving users a unified surface for requesting those permissions; If the user now was clicking on Accessibility first, the permission request dialog from macOS would correctly pop up and do its thing. All fine and dandy. When the user then clicks on Input Monitoring, nothing happens - macOS will not show the permission request dialog for that feature. Actually never ever -- even if the app gets restarted in between. macOS appears to mix the idea of Accessibility and Input Monitoring as soon as the former is setup before the latter.

The only way to get all those permissions requested and setup properly is when Input Monitoring gets requested first.

That in turn means such setup dialog would have to be a step-by-step guide -- first only asking for Input Monitoring and when that was setup by the user ask for Accessibility. Overall, the convenience gain is vastly diminished by that macOS bugfest and I decided to drop the entire idea. The flow would be very similar to what we got already, so why bothering with added dialogs.