MuseScore web

• Apr 12, 2020 - 20:21

Hi all,

I've been working on and off on getting MuseScore to run on the web by compiling it using Emscripten. With recent Qt and Emscripten releases the support for Qt on WebAssembly has greatly improved. Now with Qt 5.15, Emscripten 1.39.8, and several changes to MuseScore code, it runs pretty nicely on the web. Today I finally managed to get the palette to display correctly. There are still some quirks and major things missing - e.g. drag and drop doesn't work, save/open need to be implemented (integrated with cloud service or simply upload/export), audio doesn't work.

Demo video :
https://youtu.be/TZhzTqyepag

I forked MuseScore from version 3.3 (Oct 2019) and haven't integrated any new changes since then, here's my fork:
https://github.com/matangover/MuseScore/tree/web

Would the MuseScore maintainers be interested to integrate this in any way into the main codebase? Or should I keep it as a side project and see where I go?

Comments

• Apr 13, 2020 - 16:43

Wow, that looks extremely exciting! Being able to run remotely would be a big benefit to many people without access to a computer on which they can download MuseScore (no computer at all, or hardware too old, or install privileges locked out by system administrators, etc). But to me it also leads to the next obvious question, what about collaborative editing? I guess just having it run on the web is step one, step two would be at least as much work working out the file management and communication between separate instances, but having step one done means work could at least begin open step two?

Reply

• Apr 13, 2020 - 17:27

As far as I understand this is not about running MuseScore remotely, MuseScore still runs on a user's machine in a web browser. So people with old hardware will probably have even more performance issues with web version of MuseScore. But yes, this doesn't require a usual installation so for systems with install privileges restrictions this would indeed be useful. And the very fact that it doesn't require installation and is sandboxed in a web browser could potentially encourage more people to try out and use MuseScore.

Looks indeed great, thanks @matangover!

Reply

• Apr 13, 2020 - 18:17

Yes, @dmitrio95 is right. It still runs locally on the user's browser (just like Google Docs runs on the user's browser, for that matter). But being a web app, it could be run easily on many platforms, e.g., Chrome OS (without need for Crostini), iOS, Android (e.g. tablets).

Regarding collaborative editing, I agree, that is a natural next step, but I estimate that it would require a very substantial amount of work, plus maintenance of a backend. (Theoretically it could use something like Firebase for the backend.)

Reply

• Apr 13, 2020 - 18:21

Anyway, as a first step I was thinking of one easy way to enable collaboration (though non-realtime) - offering integration with cloud services such as Google Drive. E.g. it could probably quite easily be made into a Google Drive App that is able to edit files stored on the user's Google Drive. Then multiple users could edit/view the same file (but without realtime collaboration).

Reply

• Apr 13, 2020 - 17:34

Fantastic effort!

Out of curiosity, if this was setup to run on a remote server, how much data would users need to download?

Reply

• Apr 13, 2020 - 18:26

Thanks @shoogle. In the current extremely unoptimized debug build, the download is 73 MB for the compiled code and ~100 MB for the data (yes, that's a LOT!!). It's downloaded once and cached for further visits. Before publishing I will work on reducing the download size, but I can't really estimate what the final size would be.

Reply

• Apr 13, 2020 - 20:33

Thanks. It's already not bad when you consider that many browser games are bigger than this. The size is roughly the same as downloading and installing MuseScore the traditional way.

By "data", do you mean the soundfont, templates and workspaces (i.e. things we can make smaller) or do you mean images and resources that are used to create the look of the program itself (think UI textures, etc.). Perhaps the textures are included in the 73 MB executable?

Reply

• Apr 14, 2020 - 17:43

The data includes everything that's not the application's code, so from your examples both soundfont/templates/workspaces as well as images/resources are included. But I'm quite sure I included some unnecessary data in the build, which can be removed to reduce the size.

Reply

• Apr 14, 2020 - 17:51

It's a bit complicated to set up right now, I haven't set it up for 'public consumption', but you're welcome to try :) You can clone my fork ('web' branch), install Qt 5.15 prerelease (including Qt for WebAssembly), install Emscripten 1.39.8, create a build folder (e.g. build.wasm) and from the build folder compile using:
~/Qt/5.15.0/clang_64/bin/qmake /path/to/MuseScore/libmscore.wasm-mac-test.pro && make -j8

BUT this probably won't work out of the box, and I can't really help you further than this for now, sorry :) you will have to copy some resource files to a specific location and a few other environment setups. I will eventually work on making the build process streamlined as part of the MuseScore CMakeLists. It's just that Qt for WebAssembly doesn't officially support CMake yet so using qmake was the easiest path for now.

Reply

• Apr 14, 2020 - 17:54

Thanks! The result looks similar but the technology is completely different. "rollApp is an online application virtualization platform, which is a fancy way of saying that it hosts applications in the cloud and allows you to use them from almost any device with a web browser." However, my approach was to compile MuseScore to a WebAssembly binary so that is runs directly on a user's browser without the need for cloud servers.

Reply

• Apr 14, 2020 - 18:05

rollApp is like a remote desktop client. They have MuseScore running on a computer in the cloud, and they send you a live video feed of what is on that computer's display. Meanwhile, your browers sends them information about your mouse movements and key presses so that you can control the feed.

Reply

• Apr 14, 2020 - 20:01

This is very impressive, but I'm having trouble understanding what it is. Where is the C++ code running? In what way is this not "running MuseScore remotely"? I do not understand the architecture.

Reply

• Apr 14, 2020 - 20:57

Here the C++ code was compiled to something called WebAssembley, which runs inside your browser. It's a bit like running a Flash game or Java applet from 2005, except in this case there's no need to install a plugin because WebAssembley support is built-in to modern browsers.

So the code is running in your browser and the necessary files can be served by an ordinary webserver running Apache or Nginx, etc. Once you have downloaded it you can run a cached copy offline (i.e. without an internet connection). This would not be possible if it was running remotely.

The downside of running locally (i.e. in the browser) is that it means the user has to download the whole program, and their machine needs to be powerful enough to run it. If it was running remotely then the server would do the heavy lifting in terms of processing tasks and users could get away with using lightweight netbook devices. However, in that case you would need a special server that is capable of running MuseScore, and you would need some way to forward user input (mouse movements and key presses) from your device to the server. Also, it would only work while you have an internet connection.

Reply

• Apr 21, 2020 - 00:04

Would it be worth posting here the link that appeared on the dev channel? It seems that @anatoly-os did compile and publish it.

Reply

• Apr 21, 2020 - 09:31

I don't see the added value of that yet as it would likely just result in many users going: Nice!... It doesn't work!
What was shared is the very first "it builds and doesn't crash if you don't touch anything" version. Not yet ready as an alpha version, as no file interactions are implemented yet.

Reply

• Apr 21, 2020 - 12:31

Impossibility to access local files will be removed in next chromium version, on a site by site basis and requiring permission from the user (not unlike permissions you must give to apps on smartphone).
Do expect lot of desktop apps to become proposed in the browser.
I would not be surprised that in two years time most "base" users never install an application in the traditional way anymore

Reply

• Apr 21, 2020 - 14:27

Also note: currently the page is served through GitHub Pages, so the download (of 37 MB) is only cached for 10 minutes (GitHub Pages sends "Cache-Control: max-age=600" and this cannot be changed unfortunately). If you visit again after 10 minutes you will have to download it again.

Reply

Do you still have an unanswered question? Please log in first to post your question.