Change:
ln -s $out/Applications/mscore.app/Contents/MacOS/mscore $out/bin/mscore ''; <ins> # muse-sounds-manager installs Muse Sounds sampler libMuseSamplerCoreLib.so. # It requires that argv0 of the calling process ends with "/mscore" or "/MuseScore-4". # We need to ensure this in two cases: # # 1) when the user invokes MuseScore as "mscore" on the command line or from #    the .desktop file, and the normal argv0 is "mscore" (no "/"); # 2) when MuseScore invokes itself via File -> New, and the normal argv0 is #    the target of /proc/self/exe, which in Nixpkgs was "{...}/.mscore-wrapped" # # In order to achieve (2) we install the final binary as $out/libexec/mscore, and # in order to achieve (1) we use makeWrapper without --inherit-argv0. # # wrapQtAppsHook uses wrapQtApp -> wrapProgram -> makeBinaryWrapper --inherit-argv0 # so we disable it and explicitly use makeQtWrapper. # # TODO: check if something like this is also needed for macOS. dontWrapQtApps = stdenv.isLinux; postFixup = lib.optionalString stdenv.isLinux '' mkdir -p $out/libexec mv $out/bin/mscore $out/libexec makeQtWrapper $out/libexec/mscore $out/bin/mscore ''; </ins> # Don't run bundled upstreams tests, as they require a running X window system. doCheck = false;

Discussion:
(///) packaged in does not detect Muse Sounds Manager. The Muse Sounds profile is greyed out and cannot be used; leaving only MuseScore Basic available to use. Steps to reproduce the behavior: from (at the time of updating, version ) the unofficially packaged ) flake. MuseScore either from the desktop entry or via in a terminal, visit in the top bar, to check for available playback sounds to use. The Muse Sounds profile should be available to use and not greyed out. ! I have acknowledged the fact that although the mentioned Muse Sounds Manager package is unofficially packaged, the package works with the AppImage Version of MuseScore (packaged officially ), so I don't think this is the problem with the Muse Sounds Manager flake. Below is the screenshot of what the Playback Setup window should look like, taken from the AppImage version while opening the same score as the previous screenshot. ! I have tried reinstalling Muse Sounds Manager itself and reinstalling each Muse Sounds, but the issue persists. My entire system configuration files are . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Sorry, miss-clicked submitting the issue without adding any information. It'll be updated soon and reopened later.
Hey I'm sorry but I can't reproduce your issue. I Ran and downloaded an example font, and with both 4.3.0 and 4.3.1 I get: ! Before I downloaded the sound fonts I also had that button grayed out. Maybe you simply need to check again?
Thank you for responding. The issue persists after I've tried and and everything else (reinstalling MuseScore, Muse Sounds Manager, reinstalling all combinations of Muse Sounds) again to confirm that this is not an isolated incident. Additionally, I've compared the logs of both the AppImage version and the version. Most of both outputs are identical (apart from some timestamp-dependent data), but these lines only show up on the version: If necessary, please let me know how I can provide any more information.
Nice!

Perhaps it is related to specific sound files you downloaded with that I didn't? Perhaps can you share all those? I have only this one named .
I've tried and downloaded all Muse Sounds from the beginning again for another time just for good measure. Here's an exact order of what I've tried (only one at a time, uninstalling all other Muse Sounds) and the issue still persists: Keys Brass Guitars Vol. 1 Choir Harp Percussion Strings Woodwinds So, all of the Muse Sounds available. The terminal logs print out the same error message on the version. I've also tried each of these with the AppImage version and I can confirm all of these are recognised with no issues. Is this in some ways related to how ? (This is an uneducated guess from me noticing logs mentioning the dynamic library )
Hey and sorry it took me a while to get back to this. It'd be nice to get your approval upon the 4.3.2 version bump (haven't even built it yet): So I tried to download all of the sounds mentioned above, and still I can see the muse sounds profile... I don't know what else I can suggest to debug this :/ Wait where do you see these lines? I don't see them in either muse-sounds-manager's logs nor in Musescore's ... Log of muse-sounds-manager-nix : And log of Musescore:
It's all good :) I'm just happy someone is even looking into this, to begin with. As to the 4.3.2 version bump, what do you need my approval of specifically? I'm sorry, I'm still very unfamiliar with the Nix ecosystem as a whole. Although, I have built the 4.3.2 on my machine and tried , everything seems to work (I've tried playing some tracks, editing them, etc), including the Muse Sounds. ! Additionally, I've done some more debugging: It seems like: running in the terminal (tested with + ) doing and then in the terminal (tested with & ) launching from the Desktop Entry all had the issue of Muse Sounds not being available to use. However, doing: (in ) / (in ) , into the output directory, then do all have Muse Sounds available to use.

So this seems to be more of an issue with my shell environment somehow, and I honestly have no clue why this is the case, or where to start looking. That's a bummer. I mean, I guess I could always just use the AppImage version; It's not a big deal. Thank you for looking into it at least. Honestly, it could just be something arbitrary only in my machine in particular. Sorry, I should've clarified: The logs I sent earlier are from MuseScore (I just ran in the terminal). I didn't share Muse Sounds Manager's logs since nothing seems out of place there. Here's the full logs of me only running in the terminal and then closing the MuseScore window shortly afterwards: As you can see, line 9~12 showed the error I mentioned earlier. Again, thank you for taking your time looking into this.
Indeed this line seems suspicious.. And when you run version 4.3.2 you don't see it? I didn't find that line in my logs as well...
Yes, all other mentioned methods with Muse Sounds available don't have those errors in the logs.
It's weird because returns nothing... There is: Which may be related.
Edit: I was mistaken, setting the still doesn't detect Muse Sounds.
Yes it surprised you wrote initially it worked for you. We are on NixOS after all :). I'm not sure if you are subscribed to that issue or not, but I asked them about the source of .
BTW today I experienced crashing for me, and I checked the backtrace () and this is what I found: Interestingly: So indeed this issue is related to external shared objects that are not compatible with NixOS. I'm still a bit confused as to why in your case it doesn't necessarily crash, and instead it silently fails and you don't see the muse sounds... It'd be interesting to try to that file before you run ... In anycase, this should also be discussed with .
Hello, I've done some additional testing. It's not much, but I still want to tell you what I've found. It turns out these only work with that one MuseScore instance. From that instance, if I do or , it will always fail to load the dynamic library. I haven't yet figured out how to launch the new instance and have the dynamic library properly loaded.

So this must be something weird about my variables, some directory mismatch, or something else. I've already sent my here, but in case you haven't taken a look, I have in it (which in turn makes return ), in case there are some hard-coded paths that don't respect this nix setting and is messing up with the dynamic library lookup. Just bringing it up since there have been some Nix packages not respecting that setting and causing issues with me in the past.
Hey did you end up finding a solution to this? I'm experiencing the exact same thing, and this thread is the only place mentioning these issues
Unfortunately, no, I haven't. Whenever I need to use MuseScore with MuseSounds (which is, all of the time), I launch MuseScore by doing in the terminal, which is one of the workarounds I've stated which have MuseSounds working.
Alright, thanks! Yeah I've seen your comment above, and to my surprise did indeed work. Maybe I'll just overwrite the mscore.desktop file with this command for now (Btw, thanks for the debugging effort you've put tinto this)
is not an issue due to the way library lookup works on Linux. Since is an optional dependency, it is loaded with (in via ), and says in particular that dependencies of such libraries are looked up in directories of the executable that calls . is a C++ application, so it also depends on and its contains a /nix/store directory with , and when it loads , the latter uses the same from the nix store. You can run to confirm that it has and that its contains the directory where it is located ()
The reason , etc. do not load is that the latter contains a shady function that prevents this library from loading when the calling process name () does not end with or . When you run MuseScore in the console from PATH, the process name is simply (without ), and the library declines to load. Similarly when you open a new score from MuseScore, it launches another instance of the program with the name which also does not end with .
the f. Amazing job figuring that out! (And also thanks for the MuseSounds nixpkgs PR )
Indeed this is a very impressive investigation and conclusion . I'm a bit confused though - whether we use a wrapper or not shouldn't make a difference right?

Because the wrapper script (whether it is or ) always set to right - hence the shady function will return , at least as a of right? I wonder whether we should perform a to an absolute path in to improve 's experience described here.
I have already made a fix and will make a PR out of it very soon. MuseScore's argv0 will always end with regardless of the way it is launched, so can stay the same. (In my experience during system upgrades .desktop files are more convenient without absolute paths.)
You are right about the initial launch of MuseScore, but when you use File -New, it launches another copy of MuseScore, and it does this (as is common on Linux) by executing the target of , which is and this becomes of the new instance of MuseScore.
That's my experience as well. Ah wow, now I understand! Thanks. It means the patch will be much more involved... Good luck with that! I wonder why upstream decided to add that "check argv[0]` in the first place. The 4.4.2 release just came out, and the build locally seem to go on OK, so I just opened - marked as a draft, waiting for your magic patch.
The API of is easy to learn from , which makes it technically simple to use MuseSampler without MuseScore. For example, someone writing a VST plugin could just load and use it as a virtual instrument player in any DAW, without MuseScore. I guess that Muse Sounds authors wanted it to be tied to MuseScore, so they made it fail to initialize when loaded into a program with a different name. This is particularly clever against VSTs since a VST can't change argv0 - the user of such a plugin would have to rename their DAW to !
Wow, thank you so much for the debugging efforts you did! I'm available to do some testing if you need any.
Thanks! You are welcome to test