Marcel Blum

I think you need to force electron-forge to exclude uiohook-napi from the ASAR archive for it to work in packaged form. I am doing this using `packagerConfig` in my forge...

You can test it by looking in the folder structure of your packaged app to see if the files are outside the ASAR as desired. If successful you should find...

if you're not seeing a `\resources\app.asar.unpacked` folder then something's not right in the way you have your `packagerConfig` set up. Either the config is not being properly passed to forge...

Hi - Revisiting this 1 year later, on the same M1 MBP, now well used, updated to Ventura, and reconfigured for use as a developer's machine, a fresh `npm install...

I think this problem has been resolved with the latest version of RtAudio contained in latest Audify release 1.8.1. RtAudio's device probing was refactored and seems like it was made...

Not a fix but a workaround would be to use Electron's `systemPreferences.isTrustedAccessibilityClient()` to have more control over showing the dialog, and then only do `require("uiohook-napi")` once you know the permissions...

Assume you're talking about use with [rubberband-web](https://github.com/delude88/rubberband-web). I've experimented with it a bit but ultimately decided against using it because latency and cpu use were too high and Rubber Band...

Looks like audioWorklet support in Tone on Firefox is broken, likely an issue with standardized-audio-context, might be fixed in tone@latest if you haven't tried it. But you can also work...

Not sure what would be different about using audioWorklet in React vs vanilla js. Maybe you can be more specific about what you're trying to do or code you've already...

Tone's AudioWorklet api is pretty basic, `createAudioWorkletNode()` just returns a `standardized-audio-context`-wrapped native `AudioWorkletNode` rather than a full-featured `ToneAudioNode`, meaning that it lacks Tone conveniences like `toDestination()` and requires a bit...