Compiling to WebAssembly?
Opened this issue · 12 comments
First of all, thank you for writing genish. It's one of the most exciting projects in the space.
Do you have any plans to optionally generate WebAssembly code?
Thanks! I've enjoyed many of your projects over the years as well.
I would like to generate WebAssembly if at all possible, but I'm not sure if compiling JS -> WebAssembly is really an intended use case for WASM. Most of my use cases involve compiling graphs that are all dynamically created on-the-fly, and it seems like WASM is more of a compile ahead-of-time system, but, I'm still fairly ignorant about what its capabilities are.
It'll be interesting to see how much better it can do than "regular" asm.js... asm.js can be really fast!
Most of my use cases involve compiling graphs that are all dynamically created on-the-fly, and it seems like WASM is more of a compile ahead-of-time system
Of course.
I guess what I meant was that it would be cool to have a write once, run anywhere system based on genish. From what I saw, the code generated by genish is a function that takes a memory object + an optional number of parameters, and spits out the next sample*. If I write my complex instrument / effect, I get a callback function that generates the next sample everytime I call it. That's pretty simple, and particularly convenient because, if I wanted to "port" my synth to native, I would instinctively take that function, rewrite it in C (or compile it to WebAssembly) and write a small wrapper that calls the function, wires it to the input / outputs and pass the parameters when needed. This way, I could export my beautiful synth to - for example - a VST, or an ultra-fast WebAssembly based DAW.
Genish seems a good choice for this because it's not dependent on the Web Audio API (so no polyfilling graphs of oscillators or panners in other languages / environments) and supports per-sample computations (so, no complex reasoning/porting about n-sample blocks). It seems intentionally made to be run anywhere.
So I guess the question was: Are you planning to generate non-javascript callbacks, in the future? I would love to write my WebAssembly powered stuff and - why not - VSTs after sketching them in javascript with genish.
* which is strange, because it also modifies memory directly, but it works well for debugging.
Sounds like you want Gen :)
In all seriousness, it would be great to add more code generation targets (right now there's just vanilla js and asm.js). I've been doing some of the work to abstract the targets away in the multiTarget branch.
I'd have to be really careful making a C target to avoid copying / looking at actual Gen exported code; don't want to give Cycling an excuse to be sad at me.
Would be really fun to pair this with a web-based interface for VSTs and AudioUnits... maybe something like this paper from WAC last year:
Would be really fun to pair this with a web-based interface for VSTs and AudioUnits... maybe something like this paper from WAC last year:
I can't remember now, but I might even have reviewed that paper for the WAC :)
Seriously, a web-based per-sample plugin editor with an "Export" dropdown to web component / wasm / vst / au / raspberry / arduino standalone... that'd be a showstopper.
In case you don't know it: https://github.com/modlfo/vult
I think it's not a per-sample system (I don't know well) but it supports several targets (C/C++, Javascript, and Lua) and I think it's intended to be used in arduino/teensy & raspberry pi boards.
Thanks, @danigb!
OK, so a full thirty seconds of research indicated that it shouldn't be a problem at all to compile WASM on-the-fly in the browser:
http://webassembly.org/docs/js/
I'll start looking into this! It actually looks like it should be easier than asm.js due to better validation mechanisms in the browser... hopefully these exist in node as well. One of the worst parts about creating the asm.js target was that node doesn't validates asm.js modules that use floats... so no automated validation is possible for genish. ARGGGH.
Nope, spoke to soon, that's only for compiling .wasm modules, there's no support for compiling .wat (the wasm text format) into .wasm. Hrrrmph.
That's disappointing. I guess Gibberish could use compiled WASM ugens assembled into a regular JS graph, so maybe there are some use cases for me, but it's not as much fun as compiling everything on-the-fly.
On the plus side, there's an asm.js to wasm converter. Since I already have the asm.js target, it might not take much work at all to get all the .wasm files for a library (like Gibberish) converted. In the end that might be better than having to write a JS -> .wat compiler, even if there Is a loss in dynamism.
Yep, seems that going from wat to wasm needs an external tool: https://developer.mozilla.org/en-US/docs/WebAssembly/Text_format_to_wasm
Maybe dynamically compiling will come later? I don't see why wast2wasm can't be written in javascript, theoretically.
Ask and ye shall receive: https://github.com/ewasm/wast2wasm
Not thrilled about such a large dependency, but it's good enough to do some experiment at the very least... assuming it works ;)
Wow, 800k minified! On the plus side, it's gonna be working with browser and node :)
News, might be the ticket to wasm via webpack!
https://medium.com/webpack/webpack-awarded-125-000-from-moss-program-f63eeaaf4e15