Interoperate HTML pieces in both cloud-5 (Web server) and NW.js

[gogins]

• Rebuild csound.node.
• Rebuild csound.wasm.
• Get trichord_space.html to run from a Web server.
• Get trichord_space.html to run in NW.js.
• Get Poustinia-v5c.html to run from a Web server. Nope, ReferenceError: 'require' is not defined. Don't need this right now.
• Get Poustinia-v5c.html to run in NW.js.
• Get cloud-5 to run from a Web server.
• Get cloud-5 to run in NW.js, this is the major objective. I didn't think this through all the way, the music visualization code presupposes that Csound has a WebAudio output, this is not currently the case with csound.node. So, csound.node may need to get a WebAudio output.
• Write the least complicated NW.js app that will run an arbitrary .html composition from an arbitrary directory without installing NW.js in that directory. One obvious way to do this is to simply copy the composition into the app source directory as index.html. Another way is to use a script that creates a symbolic link from the actual composition to the app's index.html.

[gogins]

Closing this for the time being as redundant.

Re-opening because nw-builder now makes NW.js work on macOS.

[gogins]

I got NW.js to run on macOS:

1. Create an app directory with a skeleton package.json and index.html.
2. Change to the app directory.
3. Run pnpm add nw-builder -D to install nwbuild.
4. Run pnpm nwbuild --glob=false --mode=run --version=latest --flavor=sdk . to both install NW.js (in the cache subdirectory) and run the skeleton app.

[gogins]

I have many versions of Poustinia, none of which is as satisactory as the one that I apparently have lost. Of these the following are online:

• Poustinia-v6-7-2
• Poustinia Variation 5, I suspect this is the better one.

At any rate I will try to get this back to running in NW.js on the MacBook, and to put the ValhallaShimmer in and maybe some other changes.

Message from Another Planet works.

Poustinia will almost certainly work when I fix up the vst plugin stuff for Pianoteq.

It does work, but there are audio dropouts. I can't find help for them.

[gogins]

Tauri (used by Strudel) might be an alternative to NW.js, not least because application size is much smaller. I don't think so, no native addon support.

Maybe Neutralino? Better but not there yet, addons are separate processes connected using WebSockets, not as good for me as native addons e.g. csound.node.

[gogins]

I think NW.js is OK if I can turn it into a shell for running multiple pieces, rather than building an entire app for each piece.

Right now I think the only way to do this is to create an index.html that lists only .html pieces to be performed, and then runs a selected one. One puts whatever pieces one ways to perform, or links to them, into the app directory.

[gogins]

cloud-5 is not there yet. I can run index.html and from that, I can run message.html, which definitely is using csound.node.

I will try csound_loader.js in one of the cloud-5 pieces; if that works, try it in NW.js. Currently, inspecting a cloud-5 piece crashes NW.js.

[gogins]

Got this far...

misspelled option "showLineNumbers"
CsoundAC.js:9 Uncaught (in promise) ReferenceError: __dirname is not defined
    at CsoundAC.js:9:577901
    at cloud_music_no_1.html:2017:30
    at cloud_music_no_1.html:2041:10

I've been here before, without a solution. This is about Emscripten building CsoundAC for one context when it is being used in another context. My choices are:

1. Spend a fair and probably exorbitant amount of time trying to fix this.
2. See if I can get Strudel with my additions working in NW.js another way....

Depressing. For now I do NW.js without Strudel and Strudel without csound.node.

[gogins]

Here are Emscripten people discussing this problem: emscripten-core/emscripten#11792.

[gogins]

Looks like I will have to use something like this in CsoundAC.js, but using the import function in an async block:

import { dirname } from 'path';
import { fileURLToPath } from 'url';

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

Not needed after all.

[gogins]

I have Cloud Music No. 9 working in both NW.js and the browser.

There was a logic change in csound_loader.js. I had to use csound_loader.js in the cloud-5 piece and then ensure that all its references to Csound use the result of the promises. These are minor changes. This needs to merged from nwbuild-cloud-5 into at least:

• cloud-5
• csound-android
• csound-extended-node
• csound-wasm
• gogins.github.io
• michael.gogins.studio

There is a new problem, JCsound in csound.node defines csound.IsPlaying() and CsoundAudioNode in csound.wasm defines a csound.is_playing property. These must be made the same.

I must have overlooked that csound.hpp doesn't define an IsPlaying method.

[gogins]

I think I can fix this by just using the workaround flag in CsoundAudioNode.IsPlaying() instead of the async/await to the underlying Csound object. Works.