[Linux] MuseScore Flatpack package unable to use Muse Sounds

[rjb-dev]

Summary by @shoogle:

Muse Sounds works when MuseScore is installed as an AppImage but not when MuseScore is installed as a Flatpack.

It appears that the Flatpack package:

1. Is unable to access the libMuseSamplerCoreLib.so library at its default location.
2. Provides a different version of libopus to that expected by libMuseSamplerCoreLib.so.

These could be solved by:

1. Muse Hub installing libMuseSamplerCoreLib.so to a location that Flatpacks are able to access.
2. Using a static version of libopus, or a dynamic version with "custom mode support" disabled, or the Flatpack maintainer could bundle the version of libopus libMuseSamplerCoreLib.so is currently using.

---

Original issue content:

OS: Pop!_OS 22.04 LTS, based on Ubuntu 22.04
Musescore Version: OS: KDE Flatpak runtime, Arch.: x86_64, MuseScore version (64-bit): 4.0.2-, revision: github-musescore-musescore-

Issue:
After installing MuseHub and Musescore 4.02 from the flatpak, the Soundfonts (saved in the default location) are not found by the flatpak. If I install the AppImage instead (MuseScore-4.0.2.230651545-x86_64.AppImage), it does find the Soundfonts.

Steps taken:
Install Musescore 4.0
Install MuseHub and Soundfonts
Unable to access Soundfonts
Uninstall and purge Musehub and Musescore
Install Musehub
Install Musescore
Unable to access Soundfonts
Install AppImage
Soundfonts work in AppImage
Update Musescore flatpak to 4.02
Unable to access Soundfonts in flatpak

Currently I can access the Soundfonts by using the AppImage version, however I would prefer to use the flatpak, if possible.

Thanks for any help with this.

Image of mixer showing no access to Soundfonts in flatpak

[MarcSabatella]

Your screenshot shows the only new soundfont - MS Basic - showing up as expected. I guess you probably mean the new Muse Sounds orchestral library? That may not work indeed with unsupported third party builds. The AppImage is the only Linux version built, maintained, tested, and supported by the MuseScore team itself. That should always be the preferred version.

[rjb-dev]

You're right, I did mean the new Muse Sounds library not showing up.

Thanks for the clarification on the AppImage being the supported version. I'd quite like to get flatpak to work, as it's integrated with the system, meaning things like double-click to open a score work. Perhaps that's something I could look into.

[MarcSabatella]

That works with AppImage too - simply run the AppImage from the command line once with the "install" option. Now it's fully integrated - icon, file associations, etc. And you can update by running from command line again with the "update" option (it will have installed itself as "mscore4portable"). So there really should be no reason to favor an untested unsupported third party build.

[p-mitana]

That works with AppImage too - simply run the AppImage from the command line once with the "install" option

Well, it's all about "simply run with install", "simply run with udpdate" etc. Imagine doing this for every single application. And yes, you can create a script, add it to cron and deal with that.

With the flatpak/Flathub you just install the application from tour system's "software" application and it updates automatically with the rest of applications without having to run anything at all. For any Android application anyone may download an .apk, install and update it manually (which Telegram allows as a preferred option), but developers still do get their applications to the Play Store.

Currently Flatpak is more and more becoming the application distribution format for Linux (it's unfortunate that Ubuntu still pushes snaps thogh in my opinion). Users do lookup the package in the software store and what they find currently is an unofficial one. In my opinion an official flatpak package is becoming more and more important today. If not, it would be nice from the MuseScore developers to at least provide some support to the volunteers who maintain the unofficial one.

Now, let's look into the problem:

flathub/org.musescore.MuseScore#100

In this issue a few people tried to work it out and it looks like, that what is the most problematic are the paths that Muse Hub places things at. If we are correct, there are two:

• /usr/lib/libMuseSamplerCoreLib.so
• /srv/muse-hub/downloads

The flatpak build probably seems to be able to be configured to access the latter one, however the /usr/lib seems to pose a bigger problem. Possibly a solution would be to build libMuseSamplerCoreLib.so statically and place it in /srv/muse-hub/downloads along with other files?

It possibly requires some work from the MuseScore/MuseHub team, but I hope it's not a very big task.

After all, what can be achieved is a – official or not – fully working MuseScore package in the Linux distributions' app stores. Isn't tweaking a few things worth it or are there more problems we are not aware of?

[RichardJECooke]

Why don't you remove flatpak from https://musescore.org/en/download then? If it doesn't work completely, then it's just harmful having it there. People like me will download it, run it, and be unable to find the modern instruments. Then go google for what the problem is, come here, read all this, then go back to the site and download the app image. You could save everyone the trouble by not showing it, and removing it from flathub.

Snap is even worse, it's only Musecore version 2 or something.

[p-mitana]

Well, removing the flatpak would simply be a statement "we're not fixing this". And this would mean MuseScore would remain either out of Linux distros app stores or with a non-feature-complete version forever.

I'm sad it's prioritized so low. As Muse Hub is closed source, the community cannot to anything about it. At the same time it looks like an issue that would not take that much work to fix, but with a significant gain of allowing users just to install and update MuseScore and MuseHub from their distros' app stores.

[MTRNord]

The download locations also affect fedora silverblue and friends as /usr/lib is a read-only filesystem by design. Anyone but ostree is not allowed to modify it for good reasons.

[artm]

According to the documentation the default soundfonts location on Linux is ~/Documents/MuseScore4/SoundFonts. Why does MuseScore need a closed source file downloader that drops files in a wrong directory? Don't you trust your users to be able to download the files with their browser and put them where they belong?

[MarcSabatella]

That folder is for user-installed soundfonts - simple files in SF2 format. The special installers (Muse Hub or Muse Sounds Manager) aren't for soundfonts at all - it's for the Muse Sounds orchestral library, which includes dozens of files and also includes the sample player (executable) needed to use these sounds. The library is over 15 GB in size and receives updates on a very regular basis - every few weeks or so. This is not something that is reasonable ask users to manage on their own.

[artm]

You are saying they have reinvented package management just to avoid properly integrating with Linux distros.

[shoogle]

The purpose of having our own package manager for Muse Sounds is to enable (optional) peer-to-peer distribution, which is a significant cost saving given that these sound libraries total over 15 GB in size, and we're giving them away for free.

[artm]

Thank you for doing that. I have just replaced MuseScore flatpak with the AppImage, and the MuseSound violins sound amazing :-)

I retract my previous comments. I was just frustrated. I still agree with Richard that alternative packages on the official download page should either be removed or clearly marked as broken.

[p-mitana]

That folder is for user-installed soundfonts - simple files in SF2 format. The special installers (Muse Hub or Muse Sounds Manager) aren't for soundfonts at all - it's for the Muse Sounds orchestral library, which includes dozens of files and also includes the sample player (executable) needed to use these sounds. The library is over 15 GB in size and receives updates on a very regular basis - every few weeks or so. This is not something that is reasonable ask users to manage on their own.

The reason is perfectly valid and it's understandable that you cut costs in a way that still allows you to deliver good experience for users. I don't think it would make sense to ditribute Muse Sounds using a good old Linux packages, as it would require debs, rpms etc. for different distros. Custom solution is justified here.

However, this could be probably relatively easily tweaked, so that Flatpak distribution of MuseScore would work with Muse Sounds. We just need one static library and a configuration option to make muse sounds library land in a different directory (and be loadable from there by MuseScore). Then MuseScore with proper Muse Sounds support would land in many Linux distros' deafult app stores. Please consider these changes, as it will really be a notable improvement for us.