Hi all, following the README.md instructions for building the web-version of Csound (Emscripten/wasm), I run into the following. My system is Linux Mint 20, using the following emcc:
We're using nix to build the official webaudio csound builds (in the
wasm folder) and have not spent much time keeping the Emscripten build
up. That said, there's a PR that enables building with Emscripten and
vcpkg:
Re: wasm builds being the “new way” for web-based Csound:
I see that the *.nix files in wasm/src drive the build. And the wasm/scripts folder seems to be a wrapper around all that?
The brief README.md basically is about invoking yarn to do some magic. Is that strictly necessary? And does the npm/yarm ecosystem actually install, say, nix itself for you, if it’s not already on your system?
But I’m on a Linux box as a rule. Do I change that? What does it mean in this build context?
Perhaps a little more verbose instructions about how this all works together being put into the README.md would make this more approachable for those curious/unafraid to build their own wasm builds…? Once someone answers these things, I’m happy to open a PR to flesh out this for others in precisely this way.
I think Hlodver could answer better as he set a lot of this up, but
for me I have nix and yarn installed, then I go into the wasm folder
and type 'yarn build'. That build's the @csound/wasm library. Next I
go into the /wasm/browser folder and build with 'yarn build'. There's
one additional step that if you want to build the browser library
against the wasm library built in the first step, you'll have to yarn
link them together. So that's
cd wasm
yarn build
yarn link
cd browser
yarn link @csound/wasm
yarn build
From there, I'll yarn link my other web projects to the @csound/browser library I built by running 'yarn link' in the
wasm/browser folder, then in my web project I'll add the @csound/browser dependency to package.json and use 'yarn link @csound/browser' to override and use the local version (vs. using the
npm published version).
(FYI, I did notice a build issue with latest from develop; looks like
build updates to cmake and files moving around didn't get updated in
the wasm build. Will look at a PR shortly to fix that.)
As long as the built *.js, *.wasm resources are servable in general, we don’t need to use node to serve them, right? Node is an option to serve them, or run the JS artifacts from the CLI, but it isn’t strictly necessary?
Node is used to build the artifacts (what's in the wasm/browser/dist
folder) and those are everything needed to use csound on the web. You
can choose how you want to include those in your app (most typically
using a build tool like npm or yarn, but not necessary). The browser
build is meant for browser environments and not used with node. There
is a separate nodejs folder for @csound/nodejs, for running on CLI or
in a node server, but I do not think that has been maintained.
Building the wasm with with yarn build…there seems to be an upstream error in some header…have you encountered this? The whole nix R/O filesystem is…interesting…but also super annoying, b/c you can’t apply an edit to fix an include.
Yes, I mentioned there are build problems at the moment. I got it to
compile but it doesn't run as it looks like csound.nix is missing some
files for when not building plugins. (This was a recent change in the
develop branch that did not get updated in the wasm build.) I pushed
a fix-wasm-build branch that has ongoing changes in case Victor or
Hlodver have a chance to take a look, otherwise will be a day or two
before I can get back to it.
FWIW, I was building from the master branch, and it didn’t finish building at all. Googling the error, it seems like the errors were a common issue with gcc-13.2 LLVM (which I assume was a wrapper around clang, b/c I thought wasm/LLVM was a clang-only program).
Anyway, no joy on my machine for master branch ‘wasm’ either.
While this thread is happening: might I ask why there are two “web Csound” build folders/techniques to begin with? Why was Emscripten abandoned in favor of nix/nix-build? In my limited experience with both build processes, the Emscripten one felt more natural and similar to a normal C/C++ process, while the nix one felt like I had zero ‘hackability’ over the process without a lot of extra boilerplate fidgeting. E.G. the “read-only” encrypted filesystem makes the already opaque build process even more so, and to change anything like a missing #include directive meant – horrors – creating a whole framework for “patching” the 3rd-party read-only artifacts, as opposed to just opening a file in an editor and adding a line. Yuk…
Anyway, how does the “Emscripten” folder, abandoned or not, relate to the “wasm”, other than as a competing build technique?
Emscripten was first and worked okay; Hlodver was working on a
nix-based build using wasi and he optimized the build quite a bit
(pretty large difference at the time), as well as added some features
for dynamically loaded libraries. nix has good qualities for
reproducible builds but has a bit of a learning curve. At this point,
I'd like to see the nix build lean more on cmake; alternatively, it
might be worth revisiting Emscripten for the @csound/wasm build and
keep @csound/browser.
The Emscripten build did both compile libcsound to wasm (with
additional dependencies like libsndfile) as well as provided the JS
code to load and use libcsound and provide an API that worked with
ScriptProcessorNodes and AudioWorklets. The current wasm folder splits
those two into @csound/wasm and @csound/browser.
At the moment, is anyone having luck building web-csound either via EmScripten or wasm? If so, is this in the dev branch only?
I eventually gave up on it…it definitely was not easy to grok what was going on with the build, especially the nix one.
As a result, for the web project I’m building (https://untwelve.org/static/javascript_demos/microcsound.html), which is a port of microcsound to JavaScript, which suggests rendering the output .sco to Michael Gogin’s web player as an off-site location via a URL. Ideally, I want to host a csound player online on https://untwelve.org itself, which is why I want to be able to build…but alas.
So, in the meantime, I’m going to try the alternative of using tone.js to render (for folks who don’t want the inconvenience of going off-site and cutting/pasting just to hear the result). It’s not as ideal, but at least it is widely available, users will have some immediacy to the interface, and I don’t have to worry about build issues. It also seems to have decent performance and a good-enough API for my needs. Won’t hurt to learn it, either, as yet another DSP tool in the toolbox, I suppose.
