How We Made MuseScore 4 - Music App Design is Challenging! on HackerTube: recommended by 4 Hacker News commenters across 3 separate months, 2022–2026.
documentary · evergreen
Tantacrul walks through how the MuseScore 4 team was built and how design decisions were made for the overhaul of a huge legacy notation app. It covers playback and engraving quality improvements.
Recommended as a candid, in-depth look at hard UX redesign work and the limits of MIDI for notation.
“the whole video is worth watching as well”
6 Hacker News comments link this video. Each one links back to its thread.
If anyone is yet to see it, Tantacrul (on youtube) is now deeply involved with MuseScore (UX lead or similar?); he put out an awesome vid on the design of MS4 at the beginning of the year: ▶ this video His video on how Sibelius' UX is a pile of shit remains one of my favourite vids on yt: [link]
in “MuseScore 4.1 is now available” · View on HN
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]
in “Printing Music with CSS Grid” · View on HN
Maybe the segment on engraving of Tantacruls Musescore 4 video is a good explanation of some of the things involved: ▶ this video the whole video is worth watching as well (and there are several videos on the channel focusing on the UI of notation apps, worth watching for anyone who does UI but isn't interested in music production as well)
in “Printing Music with CSS Grid” · View on HN
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.
in “In praise of MIDI, tech’s hidden gift to humanity” · View on HN
> 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
in “Nothing works and everyone is euphoric” · View on HN
> 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
in “Debian KDE: Right Linux distribution for professional digital painting in 2024” · View on HN