move audio logic to hidden worker instance about hyperamp HOT 4 CLOSED

This would allow us to more easily open/close the library window while the player is still going and also include a menubar process. The three could communicate and stay in sync with IPC messages. Only caveat is I think we'd need to manage communication between renderer processes on the main thread using ipcMain since I think ipcRenderer can only communicate with the main thread and not renderer siblings. That should work out well though since we probably want the main thread to act as the canonical store for audio state.

from hyperamp.

This sounds like a good next step, although I am curious to see if there are any advantages to eventually using any of the c++ libs or http://audiocogs.org library outside of a window process (either in the node/main process or with a fork worker and messaging over IPC).

from hyperamp.

Might be worth investigating but be warned packaging an electron app for distrubition and including compiled/native code from a third party is not an obvious problem to solve (at least for me in the past).

Would be interested to see how it's done as I'd like to distribute https://github.com/ungoldman/himawari-bg as a menubar app but have not figured out how to include imagemagick & graphicsmagick in the bundle yet.

from hyperamp.

I think it depends on the native module packaging. Some require unbundled external shared libraries (like imagemagic right?) and others bundle the dependency into the native module (like https://github.com/paixaop/node-sodium) that can be fully installed with npm when the build environment has the gyp requirements (e.g. c++ compiler, python etc.)

I've never done packaging for something like that before, so there are sure to be sharp edges, but I think its possible. Learning more about how to bind to C/C++ libraries is also something I've been interested in learning how to do for a while.

from hyperamp.