How We Made MuseScore 4 - Music App Design is Challenging!

The recent video on MuseScore 4 has a fascinating (though simplified) perspective on how limiting MIDI is: ▶ this video MIDI's issues in a notation context are twofold: non-standardization of controls for e.g. choosing articulations for string instruments, and an inability to communicate future information if known to the MIDI producer - say, for instance, knowledge that this Note On event is the beginning of a phrase that will last for 2 measures, as known to notation software. There's a real way in which MIDI solved for communicating trigger events over the wire, but was not extensible enough to allow for further backwards-compatible standardization that would let it communicate music over the wire. By contrast, the web evolved from communicating hypertext to sending entire application environments and executable code over the same protocols. The web was born later, to be sure, but in an age where an Arduino can execute JavaScript, I wish we were looking to much more extensible modes of communication as inspiration for what can be done with interoperable musical devices.

> The solution is to gut your product org, replace management with leading engineers, and hire some of your most fanatic users. They don't need to do anything other than give their opinions, and use the product every day. Put them in a room with your top engineers, and the software will mysteriously get better. This will just lead to massive selection bias. If all you care about are power users go for it. Otherwise you end up with a complicated system that is going to put off new users. You can even have different power users who likes different parts of the software. Now it's totally possible to end up with extensive subsystems that don't really gel with each other My anecdote for this is the the recentish redesign of Musescore. Tantacrul, the ux designer/product manager for Musescore has an hour long video on how he redesigned the interface and UX of the software. He is also a musician so you can call him a power users if you want but that was not the users he had in mind when redesigning the UX ▶ this video

> Why do we get the free magic of people making great backward compatible code with other projects and so painfully not with this one? And I explained what the difference is. These projects are old and difficult. Most open source projects are neither. There are very similar problems with open source domain-specific tools, for example (Musescore, GIMP, FreeCAD, KiCad before CERN decided to fund it, etc.). Musescore has a nice video about how hard fixing it was and how hard it was to get to Version 3 and then trying to get it to Version 4 and how lucky they sometimes had to get: ▶ this video

That's very much it. You could also make an analogy to the arts of typography and typesetting. It's of the same importance to a composer or musician that the notation is legible and beautiful, as it is to a graphic designer or reader that type and layout are legible and beautiful. If the GP is interested in the topic, there are great videos by Tantacrul on his experience redesigning the notation font for MuseScore [0] and his overview of MuseScore 4.0's engraving improvements [1] - in particular this second video, concerning mainly layout, shows just how far this CSS approach would have to go to have a truly legible, reflowable layout in the face of beams/slurs/ties. (I don't want to take away from anyone on the Sibelius team, they're likely even better experts on the subject than Tantacrul is, but as far as I know, they didn't make long-form Youtube videos about the topic! He also likely got the job of leading the MuseScore redesign thanks to his previous videos that critiqued and reimagined the interfaces of music composition software... including older versions of Sibelius [2] and MuseScore [3]) [0] link [1] ▶ this video [2] link [3] link