Hi,All:
I am working on juce 7 to wasm now, planing core audio-related modules supports:
Fun! Good luck! We will be tracking your progress and can serve as a test point when you need it …
the example works fine;
auto deviceManager = new juce::AudioDeviceManager();
auto& types = deviceManager->getAvailableDeviceTypes();
auto webAudio = types[0];
auto device = webAudio->createDevice("O","I");
device->open(1,1,44100,256);
device->start(nullptr);
in the next time, I will be try to point MIDI related stuffs.
I am working on build tracktion engine for wasm now, and it’s successful build wasm file, fixed all compile-time error, but a lots mock impls, then I will:
wasm file tooooo big now.
Do you have this on a branch somewhere I can test with?
There are ways to shrink wasm code size, see
I have not pushed it to a public area now, I will try to test the basic feature first in the next few days.
yes, it’s looks good. thanks.
after wasm-strip, wasm file size reduces to 6MB, it’s should be very well.
There are a lot of native methods that need to be implemented inside JUCE, and in the current version most of them are done with empty implementations (except audio device / midi device) in order to pass compilation as soon as possible. I am thinking about the implementation of the following modules:
1. file system.
Chrome File Access API allows users to open a picker choose 1 or more files, and then read and write. looks like it’s fine working for project file. But it can’t actively read or write files, so it doesn’t work for audio files needed by midi plugins (e.g. sf /sfz player). I’m thinking of a technical solution for reading files from the server quickly so that nfs over HTTP or nfs over Websocket can be realized.
Local FS over Chrome File Access API and NFS over HTTP it’s both needed.
2. Thread Pool
The fact that wasm allows the use of pthread, so thread pools for multi-cpu processing are possible, is my next goal.
All the parts about the GUI I’m going to skip, mainly because I’ve currently chosen QT as my UI solution and have tested that it works well, so I’m not going to spend time on the parts about real GUI rendering.
Hi! What is the status of this? Do you have a repo?
I have been working hard to make the ISC licensed modules of juce7 running on wasm. This example uses these (with a special crafted juce_audio_device for browsers using AudioWorklets) and Rive for rendering:
YUP! On Emscripten
yup/examples/graphics/source/main.cpp at main · kunitoki/yup · GitHub
Very cool…! So you’re there using YUP! for the audio and JS/Rive for the UI, right?
Yes, the juce_* modules in yup are enhanced juce modules with wasm support in the browser via emscripten. Rive for the UI allows to target webgl/webgpu on the browser, as well as vulkan/gles on android, metal on apple, direct3d/gl/vulkan on windows and gl/vulkan on linux, all with 60fps and smooth animations. But it’s using their native renderer.
How would you suggest I go about compiling a simple JUCE project written in JUCE v8 for WASM at this moment in time? All the previous git hub projects give me errors when trying to run the make file in emscripten
Juce v8 isn’t ready to be compiled to wasm. Nothing works out of the box, filesystem, threading, message manager, audio. All need to be adopted and finetuned to run on emscripten
so juce v7 is the latest version?
Well, juce never really supported being compiled via emscripten
I understand but I was just wondering the easiest steps for me to be able to do this
