[Csnd] Webaudio Csound - 6.17.0-beta1
| Date | 2022-01-02 16:30 |
| From | Hlöðver Sigurðsson |
| Subject | Re: [Csnd] [EXTERNAL] Re: [Csnd] Webaudio Csound - 6.17.0-beta1 |
| Attachments | 2022-01-02 17.29.53.png |
This is the underlying toolchain: https://github.com/WebAssembly/wasi-sdk It is using patches to activate Emscripten dynamic loading mechanism. These patches and build scripts are tied together with nix package manager. Which makes them very reproducible and less prone to random faults, but does make it harder to get it running natively. I also think custom Clang compiler isn't something that is nice to have running globally on one's computer. Long story short, I recommend building with the Docker image, I think wasi-libc will get better supported with Clang, so that it can just build without any customization, not sure if Clang is there yet today. Another alternative is to build csound statically like the older Emscripted did, that would not require any magic, and wasi-sdk should in that case work out of the box as is. The javascript code has mechanism to detect whether it's running csound from statical linking or dynamic one, and it should support both without problems. The end product is a single javascript asset that will have the binary output inlined as base64 string. It's currently using google-closure-compiler (previously we started with Rollup), that depends on java being available on your system, other than that, it's yarn and nodejs for building the js asset. If in doubt, there is a github workflow action that now runs to build and test this new wasm, so it's a good point of reference for how to build the wasm asset from scratch, also, the build also stores a zip file containing the build artefacts, so in theory it is possible to download this lib.zip file and skip the whole clang sdk process and use the assets from the github workflow. On Sun, 2 Jan 2022 at 11:29, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
|
| Date | 2022-01-02 16:39 |
| From | Victor Lazzarini |
| Subject | Re: [Csnd] [EXTERNAL] Re: [Csnd] Webaudio Csound - 6.17.0-beta1 |
| Attachments | 2022-01-02 17.29.53.png 2022-01-02 17.29.53.png |
|
Is closure required for running or just for building?
It does look fairly more complex to build locally than the old emscripten build that was just a shell script and cmake.
Prof. Victor Lazzarini
Maynooth University
Ireland
On 2 Jan 2022, at 16:32, Hlöðver Sigurðsson <hlolli@gmail.com> wrote:
|
| Date | 2022-01-02 17:00 |
| From | Hlöðver Sigurðsson |
| Subject | Re: [Csnd] [EXTERNAL] Re: [Csnd] Webaudio Csound - 6.17.0-beta1 |
| Attachments | 2022-01-02 17.29.53.png |
The build is two parts. 1. native wasm: which will be the basis for any runtime supporting wasm (wasmtime/wasm3/nodejs/v8...) 2. browser bundle: which packs the binary as inlined base64 and includes bindings for webaudio Closure is required to build the browser bundle, after the csound.js exists in dist directory, it's then only a matter of serving it like any js library. The complexity imo, revolves around step1, and for any javascript contributor, this step is totally skip-able, as you can cd into wasm/browser, do yarn install, and then yarn build. The binaries are published to npm as its own package @csound/wasm while the browser bindings are another @csound/browser. On Sun, 2 Jan 2022 at 17:39, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
|
| Date | 2022-01-02 17:54 |
| From | Steven Yi |
| Subject | Re: [Csnd] [EXTERNAL] Re: [Csnd] Webaudio Csound - 6.17.0-beta1 |
| Attachments | 2022-01-02 17.29.53.png |
Should note that if you have the nix package manager installed (https://nixos.org/), building is very simple (on macOS at least). Once you install nix, you go into wasm folder and type "yarn; yarn build" for the wasm and cd into wasm/browser and type "yarn; yarn build". That should be it I think. nix will download and compile all the dependencies (clang, llvm, libsndfile, wasi, etc.). It takes a while the first time building the wasm folder but after that it's fairly quick. On Sun, Jan 2, 2022 at 12:00 PM Hlöðver Sigurðsson <hlolli@gmail.com> wrote:
|
| Date | 2022-01-02 18:01 |
| From | Victor Lazzarini |
| Subject | Re: [Csnd] [EXTERNAL] Re: [Csnd] Webaudio Csound - 6.17.0-beta1 |
| Attachments | 2022-01-02 17.29.53.png 2022-01-02 17.29.53.png |
|
ah, that's very handy.
Does it use CMake? Do we need to worry about keeping things in sync with CMakeLists.txt?
Prof. Victor Lazzarini
Maynooth University
Ireland
On 2 Jan 2022, at 17:57, Steven Yi <stevenyi@gmail.com> wrote:
|
| Date | 2022-01-02 18:11 |
| From | Hlöðver Sigurðsson |
| Subject | Re: [Csnd] [EXTERNAL] Re: [Csnd] Webaudio Csound - 6.17.0-beta1 |
| Attachments | 2022-01-02 17.29.53.png |
It doesn't use CMake, but I think we should use it. It's a bit of mess, I started off compiling csound file by file, to patch away issues that I was dealing with. It makes wasm built easily fail if files are moved, renamed or added. But I think we should work on simplifying it and use CMake to build everything. This is a big ugly point I forgot to add. But only until recently, I didn't touch any file not under the wasm directory, so I applied hacky patches shamelessly from the nix build process. But I believe the most important patches, most of which relating to mutex imports and c++ plugins, are now in the csound proper source code, so the need to maintain a seperate list of source files isn't as needed as it was when I started off. I will make sure that eventually we are using CMake. If the wasm build fails, just ping me until this transition has been made, and I'll fix. On Sun, 2 Jan 2022 at 19:01, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
|
| Date | 2022-01-02 18:54 |
| From | Victor Lazzarini |
| Subject | Re: [Csnd] [EXTERNAL] Re: [Csnd] Webaudio Csound - 6.17.0-beta1 |
| Attachments | 2022-01-02 17.29.53.png 2022-01-02 17.29.53.png |
|
I think it would be good if CMake can be used, otherwise we will need to keep the build in sync by hand. We're doing it for Android and that is a pain because we forget and then have to fix a broken build.
Also there's the other thing that some header files are auto generated by CMake, and if you use static versions of these, they may get out of sync too.
So if it's possible to use CMake, we should do it as soon as we can.
Prof. Victor Lazzarini
Maynooth University
Ireland
On 2 Jan 2022, at 18:12, Hlöðver Sigurðsson <hlolli@gmail.com> wrote:
|