Kvetch: MuseScore 2.0.2 install (on Mac) will remove installed soundfonts if you put them in the "wrong" folder

• Jul 18, 2015 - 11:02

I just installed MuseScore 2.0.2. When I loaded the DMG on my Mac (running Mavericks though that is not important), I was presented with the typical icon shortcuts for my Applications folder and the MuseScore app. The instruction is to drag the app into the folder. I did this, not thinking too hard about it. Naturally Finder (the windowing application on Mac) presented me with a message saying there was a prior version of MuseScore 2, and did I want to overwrite it? Again I didn't think anything of it - I just clicked "OK" to overwrite.

When I opened up MuseScore I discovered all my soundfonts were deleted - no way of recovering them directly. I had to find them all again online and re-download and re-install them back into the "sound" sub-folder. Which was the wrong thing to do.

Only after I started on this bug report did I think to read the user manual about soundfont location. Originally when I started adding soundfonts, I just searched to find where MuseScore was storing the soundfont it came with. Then I put my soundfonts into that same folder. Well, this is the wrong way to do it because this "sound" folder is inside the app package, which gets deleted entirely each time upgrade. There is a more complicated process in which you add your own soundfonts to a MuseScore folder inside your ~/Documents folder.

I guess I shouldn't complain. I bought the MuseScore book and have read some of it. I try and read the documentation online. It is a semi-volunteer effort all around so sometimes there are glitches. I am just annoyed that the way the application is structured, you can't learn how to do certain things "correctly" very easily - you have to consider that maybe what you are seeing is not what you are really supposed to see, because the application has been built in such a way that certain things can be done more than one way and one of those ways is going to cause you a headache. Oh well the price is right.

i do wish MuseScore could install its initial soundfont in the user subfolder in Documents, rather than retain the "sound" folder inside the app package. That way no confusion over two different folders and no way for someone like me to get it wrong by trying too hard rather than sitting down and reading the documentation cover to cover.

ALSO - the documentation for the Mac version should be revised to say that when you get a soundfont file you want to add, you should control-click (or right-click if you have a magic mouse or similar) and choose to open the file with MuseScore. Do not assume that the user will have sf2 or sf3 files associated with MuseScore. In my case they are associated with Polyphone.

Comments

• Jul 18, 2015 - 11:31

It is more a matter of user experience design than of "putting stuff into the system location." Users don't know what is supposed to be okay and what is not - we don't come out of the womb with "do not put personal things in a system folder" stamped on our forehead. In short developers must anticipate that users will sometimes be klutzes. Why are we klutzes? Because we are trying to keep upright while dancing on a landslide. GUI software from the beginning has been inherently confusing and prone to blowing up, & each new upgrade to an OS or an app makes the paradigm ever more confusing & ever more fragile. Read "In the Beginning Was the Command Line" for some really trenchant bitching about this.

Reply

• Jul 18, 2015 - 12:50

So you want to make it personal. Well, you went first. I will say that there is not much cure for developers with attitudes like yours, either.

When I was working (up until a few years ago) I used to document software of all sorts - I was a technical writer. I used to work closely with developers of not just software but what is now called "user experience." I don't know what it's called in Germany but I'm sure a term exists.

It is curious and ironic that even as software supposedly becomes easier to use - at least that is always the supposed intent - it gives rise to exponentially more user complaints and bad user experiences every year. My comment about the complexity of this obviously went over your head. I hope there are other developers on MuseScore who are more aware of the tensions here.

Another way to put it is that developers ask of users both that the user be really stupid - for example, they should not even know that there are system folders - and really smart - for example, they should read a confusingly written and badly organized user manual cover to cover before venturing to use the software; and they should understand without a problem all the confusing new GUI conventions that the developers are bringing forth. This is not altogether the developers' fault. It is more of a systemic issue.

I have actually made two concrete suggestions here that you have chosen to ignore. First, consolidate the location of soundfont files in a single safe, user-accessible location. There may be technical reasons why this will not work; but nonetheless that is my proposal to explore. It might reduce user error, which if we get beyond an attitude of arrogance is actually a good thing. And second, redo the documentation to acknowledge that some users in OS X may have sf2 files associated with an application other than MuseScore. This is a very small suggestion but would nonetheless be useful to the sort of users who follow instructions in a handbook dutifully, only to find, with dismay, that the instructions do not match reality.

Meanwhile you have offered nothing of concrete value in this exchange. Now, I do not enjoy ad hominem confrontations. If you don't start them, I won't either. How about that?

Reply

• Jul 18, 2015 - 13:31

Nothing personal was intended, nor any confrontation, sorry if it came across like that.
Feel free to improve the handbook, every logged on user can.
Most software uses this separation between system wide and resonance files, ever since multi user OSs became available. And usually the OS make it difficult for normal users to put fies into the system location

Reply

• Jul 18, 2015 - 13:45

Hi,

We tried hard to make the process of installing soundfonts easier. In MuseScore 2.0, you can install soundfont at the "right" place by double clicking them. Or right click > open with MuseScore. I believe it makes the process easier than in previous version but we can always improve.

Moving the default soundfont to the user space is not a solution according to me. It would make it easier for users to delete it and end up without sound at all.

Regarding documenting the process better, it's a great suggestion! Feel free to edit the soundfont page yourself. The documentation is a wiki and you should see an Edit tab.

If you have other suggestions, feel free to share them

Reply

• Jul 18, 2015 - 16:04

OK - yes, I thought there might be some downsides to putting the default in a user folder. Probably there is some other clever way of making it harder for a user to do what I did, but it's a relatively small concern.

And I have gone ahead and made the edit in the doco about what to do if you double-click a sf2 file and it opens in an application other than MuseScore. That page is at:

https://musescore.org/en/handbook/soundfont-0

Reply

• Jul 18, 2015 - 16:05

Generally, it is the operating system's job to make it hard to write to a system folder. I would have thought Mac actually *did* make that difficult, but maybe not? Certainly Windows would require you to have administrator privileges and popup dialogs asking you to confirm the action. Linux would generally require use of "sudo" to give you "superuser" privileges in order to do something like that.

Reply

• Jul 18, 2015 - 16:32

Mac puts up an initial barrier, yes. It is not merely admin privileges, for in the Mac world, all users must be admins if they want to install software. Probably the only place where an everyday user isn't also an admin would be in a corporate IT setting. The real barrier OS X throws up goes back to its Unix roots and is sudo. But it's easy to sudo and many users end up learning how to do this out of self-defense. Basically this is part of what I was talking about: OS environments have gotten so complex, and break so often (Apple is at least as famous as Microsoft for releasing OS updates that contain multiple bugs), that power users inevitably must take on sudo'ing or Registry manipulation or whatever else may save their ass when Microsoft or Apple will not.

Again this really is the tension I was talking about. Users are supposed not to know about things like system folders, and naïve users indeed do not; but naïve users often run into problems they cannot solve. They have no recourse except to turn to geeky friends or the Apple bar or what have you. There's a lot of misery out there. Whereas power users will try to solve things, sometimes make it worse, but at least have a feeling they can do SOMETHING.

The illusion here is that all of this is for the user's own good. It's not. It's been good for Apple and Windows and the software and hardware industries. But users are now routinely treated as alpha testers and they have no choice but to accept it. If you think I'm mistaken, just consider, which are the most democratic computer platforms? Which are the platforms that actually give users a choice of how bleeding-edge or not they wish to be? Obviously, the Linux distros. And there the majority of users are power users and sudo is something they use every day. And there is constant sharing in the distro forums of how to mess with system files. I used to boot Gentoo so I've been there.

So there really should be a better way of thinking about how to protect users from messing with system files than just "Oh you're not supposed to KNOW that there is a Library folder," which is one of the jokes about OS X. There are freeware apps whose only purpose is to allow tens of thousands of Mac users (if not more) to quickly make the Library and other system folders visible without having to mess with the command line. And they want access to the Library for pref files and caches and so on. Only that way can they fix the things that are constantly breaking and that no one else will fix for them.

Reply

• Jul 19, 2015 - 04:09

Hi UsableThought,

Just wanted to say thanks for improving the documentation on the SoundFont page. It's a good point, and I can think of one or two other places in the Handbook where the "better not to modify the system folder" information ought to be made clear.

I did once have a similar experience, where I changed something in an application bundle and then lost it when I replaced the app bundle with an update (though that was just a silly little thing where I changed the icon and PLIST file to make Thunderbird seem to be Apple Mail). However, there's always a first time for any mistake, and getting burned is an effective way to learn about fire.

For what it's worth, I don't really know how this might apply to other operating systems, but I think for OS X most of the hidden system folders (and $ defaults write com.apple.finder AppleShowAllFiles -bool true; killall Finder is the only Terminal command I have memorized) aren't actually replaced when you update an app; only the application bundle itself is replaced (assuming you're dealing with the most common "drag icon to Applications folder" situation; PKG files can do other things).

Reply

• Jul 19, 2015 - 14:06

Thanks. I am thinking it might also be a good thing to add a link from that page to the page describing use of the Mixer to select instruments for a score - the current wording on the SoundFont page is a little misleading. But I do want to make sure that my understanding is correct: Specifically, what I have done is install multiple soundfonts, and then, for any given score, go inside the Mixer and choose the instruments I want from whatever soundfont has the best sound for that instrument. Is that the approved way of doing it? If yes, then I want to add to the SoundFont page that it is okay to have multiple soundfonts installed if your system can handle it; and then add a link to whatever page of the handbook describes assigning playback sounds to individual instruments in a score.

- - -

Separately, I think you're generally right about the distinction in Apple between system folders within applications, where the executables and resources to support those executables live, versus "Library" type system folders, where pref files and other support files live - the former is overwritten when a new app is installed whereas the latter are not usually overwritten. However this is not an absolute distinction, only a convention.

Also things can and do get confused because of tension between the older Unix conventions, in the background, and the newer OS X conventions (e.g. app packages) in the foreground. For example, many shareware apps require Unix executables for certain functions (a good example is the VLS audio app) and so these either get installed by default inside the app package, or the user is asked to manually install them inside the app package. So when that app package gets updated, the executables inside do indeed get wiped out and must be reinstalled. Or variations thereof, such as when one app wants an executable and you search and find it inside another app package. Etc. There's a lot of chaos in the OS X landscape about how to handle important "extras" such as Python, Unix programs, Wine, and even to some extent Java.

Reply

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