Better scores for the Web (a demo)

• Jan 29, 2021 - 14:40


I post a lot of scores fragments on my website and since a few weeks, I've been working on improving the experience for the end user.

Here is a demo:

(see past the first few paragraphs)

The key features of my customized score player are:

  • scores are plain svg (so look good when resized)
  • scores are responsives (they stay readable on small and big screens)
  • scores are interactive: you can see what notes are being played (like in Musescore's interface) and click on notes and chord symbols to ear them. You can also browse the score by using keyboard arrows.

To do this, I use a mix of javascript and a custom annotated svg format that I got by manually patching musescore's code.

My patch is a bit hackish and not much more than a prototype, so I was wondering if it was worth pushing a pull request?


This is a cool idea, and definitely along the lines of where I think many of us seeing MuseScore move. but I'm not understanding the "adaptive" part. To me that should me, the measures themselves reflow across systems, so with a large screen you might fit five measures on a system but on a smaller one you only fit three. I don;t see your demo do this, nor would I expect that to be possible just working from an SVG. This requires actually changing the page size within MuseScore and doing a relayout. Which is the sort of the thing the mobile apps do, but not as well as they could because apparently that code was written before automatic placement was implemented and apparently never really fully integrated with the rest fo the MuseScore layout code.

To me, that's what needs to happen - the mobile app code needs to really use the full MuseScore layout capabilities. If there is a way for ordinary web apps to somehow hook into the MuseScore layout code that would be incredibly cool, but at that point, now you're also half way to solving the problem of making MuseScore itself run on the web, and now wer'e talking a bigger problem that is even more worth solving.

Which is to say, to me that's the much more interested direction to be investigating but also, not the sort of thing that I think is well suited to individual contributors. This is the sort of effort that needs to be planned, designed, and implemented with full direction from the core team.

In reply to by Marc Sabatella


You are right saying that this is not more than an interesting prototype, and the solution I came up with is really a bunch of hacks stacked on top of each others.

As for the responsive part, it's just a hack as well. I just have a bunch of musescore style files with different page layouts. I use a script to export the same score onto five or six svg files with different widths. In my html, I use html's native with multiple sources combined with media queries.

I'm not familiar enough with Musescore's layout code to try to port it to js, and I can only imagine it would be a hugh task in itself.

Anyway, it was fun to hack around in Musescore and the result is far from perfect but it covers 80% of the needs for 20% of the efforts. In case anyone has the same needs, I'd be happy to share the code.

In reply to by Thibaultj

Your approach probably makes sense.
Reflow on the fly is nice in theory, but you don't want to have a fractional number of measures by line (except in some very special cases), and you don't want to have let's say more than 16 measures by line for readability, even on huge screen.
So presaved svg for 4 screen sizes is not a bad approach.
They have also the advantage of no computing power needed at browsing time, and using caches on server with no MuseScore rendering engine is possible.
It has also the enormous advantage that the score author can check the result for the 4 sizes and be pretty confident that it will be correct for any reader once these 4 fixed results are validated.

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