Audio output device setting is lost after a crash and restart
I've been importing some of the PDFs from my old lessons (with the Musescore.org PDF uploader / converter), which tends to create slightly corrupt files that crash MuseScore when I edit them. That's not the issue I'm reporting though, just context.
Lately, I've been setting MuseScore to use a different audio output than the default output, on my PC (Windows 7 Pro SP1 x64). The setting is in Edit->Preferences->I/O. All I do is choose the device, off the list.
After a crash, when I start it up again, the setting is lost so I have to set it again, then restart MuseScore a second time, to get it to use it. All is then well, until the next time it crashes - it goes back to the default audio device, every time. After a normal shut down and start up, the setting is kept, as I'd expect.
Yes, I could set the device I use for MuseScore as the system default audio device, but I have reasons for not wanting to do that. That output goes through a ground loop isolator, to eliminate most of the hum when I use it with my little 2CH mixer - which I use to mix in MIDI based instruments, used with one of my wind controllers. Since the isolator mangles the bass a bit, I don't use that output for any other purpose, and I'm trying to avoid having to swap cables around each time I use it.
So, what I would like to happen is for MuseScore to remember the output device setting, after a crash and restart, instead of reverting to the default output device.
Is there a workaround for this, in the current version (other than restarting MuseScore twice after each crash, as I'm doing now), or would it have to be fixed in a future update?
Comments
I'm not sure I understand. *No* settings changed during the current sessions are generally remembered after a crash - in MuseScore or any program. So if you are experiencing crashes, the usual way to deal with this in most software is to make your setting changes, do a clean exit, then start the program again to do your real work. Then if it crashes, the setting changes you made previously are intact. Does this not work for you?
In reply to I'm not sure I understand. by Marc Sabatella
I'm not sure about the "any program" part - settings can be written to a file, or to the registry, as they're changed. I can't think of instances of this happening with any other software I've used.
But, yes, that may well be what it is. I thought I must have exited MuseScore normally, at some point, but doing that does appear to retain the setting, after the next crash. I guess I normally leave it running, until it crashes - which is quite often, because I'm mostly working on tunes I imported somehow, not created directly in MuseScore.
I should mention, I've done this over and over again, in the last couple of days. To me, this behaviour is not intuitive. I can see the usefulness of being able to revert to older settings, but I wouldn't have expected that to happen by default.
Is there any chance that MuseScore will one day just complain that there's something a bit iffy about a file, instead of crashing? It's a little bit unsettling.
In reply to I'm not sure about the "any by AndyHornBlower
It's certainly possible to arrange things so settings save immediately rather than on exit, but most programs I am familiar enough with to have messed with settings then have seen them crash do it the same as us. I'm sure there are exceptions.
Anyhow, sure, ideally we wouldn't crash no matter how corrupt a score is. It's just hard to insert appropriate checks into every single calculation.
In reply to It's certainly possible to by Marc Sabatella
I haven't done much programming lately, but could it just be down to things like not handling exceptions for errors like divide by zero, not checking indexes before using them to look up things in a table, and so on?
I don't mean to be critical, but it does seem rather fragile. Programs that crash when they're given bad data raise the question of whether it's possible to exploit the crash, like the old buffer overrun scenario. I would hope modern OSs are now robust enough to stop that being a problem, but it's probably better to avoid the possibility of that sort of thing happening, and have the program handle errors gracefully. If it's crashing because memory its using is getting corrupted / overwritten, that's not good.
In reply to I haven't done much by AndyHornBlower
and so on, and so on, and so on :-). We already do a fair amount of this sort of error checking when it comes to the sorts of things we "expect" to maybe go wrong, but we can't really predict what sortds of errors other programs might make when creating files for import. And there are probably tens of thousands of places we'd potentially need to add such checks in order to avoid any possibility of crashing on bad input. Which would not only be a huge effort, but it would also slow down score processing noticeably.
To some extent, better exception handling *after* the error could avoid crashes - instead, we could simply put up a dialog saying the file is hopeless and then automatically close the file. But if memory corruption has already happened, it's probably too late.
Perhaps better would be if someone were to write a MusicXML sanitizer that could detect and fix the errors most commonly made by various MusicXML-producing programs.
In reply to and so on, and so on, and so by Marc Sabatella
I haven't seen the code, but setting up exception handling (e.g. dividing an integer by zero, and so on) shouldn't slow it down noticeably at all. It ought to be less work to do that than to write a separate application to validate files too.
If you're getting memory corruption, then you're doing some sort of pointer / array manipulation that doesn't check that you're staying inside the chunk of memory you should be in. If that's happening, you really should sort it out. One approach is to write a class to handle the sort of data involved, with safe checking built in. E.g. if it's handling an array, it should know how big the array is - have a maximum index, and check the index that's about to be used is in range. If not, throw an exception, to be handled elsewhere - in the main body of code. Likewise pointers into allocated blocks of memory - have the block of memory handled by a class that checks that the offset stays inside the block of memory before you use it, that way there can't be any corruption; you've just detected that there would have been, safely.
These things are probably a lot easier to do if you do them as you're writing the code, but the general principles are fairly straightforward, so it's not too hard to add them - and at some point, you really should.
There's no real reason why you shouldn't be able to feed the software total garbage, and have nothing worse than it detecting a file it can't handle, and saying so. I can try to open an executable in a text editor, for example. I don't expect to be able to read it, but if the text editor is well written, it won't crash.
In reply to I haven't seen the code, but by AndyHornBlower
Yes as I said, exception handling is easy. It's the rest that takes effort. It's not hard, just time consuming. And MuseScore is a small team of volunteers. More help is always appreciated, if someone wants to take on a project like this!
In reply to Yes as I said, exception by Marc Sabatella
Fair enough. I will add that to volume three of my To Do list :)
Is the source code publicly available?
Just for the fun of it, I opened MuseScore.exe in Metapad - a small but useful text editor. Definitely not the sort of data it was expecting, but it was fine with it:
In reply to Fair enough. I will add that by AndyHornBlower
MuseScore is open source, so yes, it's publicly available. See the Development link in the menu at right of this page.
The text editor analogy is not very good, FWIW. A text file is just a sequence of characters, could be any characters whatsoever and of course the editor should be fine with it. Said another way, a text editor doesn't need the characters to "mean" anything; one sequence of bytes is as good as another. I don't think you'd be able to create a file that was *not* a sequence of bytes.
So,more to the point would be to try hacking up a Word document - implanting various types of semantic corruption into the .DOC file - to see how Word handles it. As with MuseScore, my guess it would gracefully handle some types of corruptions, but choke badly on others. It may well be Word manages not to crash, as it probably has benefited from 10,000 times the testing and development effort over the years than MuseScore has had. Try the same experiment with LibreOffice, and then maybe some progressively smaller projects that also require their sourc e files to make semantic sense, and you'll probably see behavior that more and more looks like MuseScore's. I've seen photo editors crash on corrupt image files, organizing programs crash on corrupted database files, web browsers crash on bad metainformation, email programs crash on badly formatted headers, etc - none of which is ideal of course, but pretty much par for the course when dealing with sufficiently complex input.
In reply to MuseScore is open source, so by Marc Sabatella
I've seen text editors crash when opening non-text files. I agree it's not the same thing, but it's a very basic case of the problem - garbage in is entitled to produce garbage out. If it produces a crash, that's down to the programmer.
Here's MuseScore.exe again, opened in Notepad, as supplied by Windows 7. Missing from this picture is the little whirry "busy" symbol, that never goes away.
The usual way this happens is that the programmer allocated a block of memory for each line of text, making the assumption that it would never exceed a certain length, then never testing to see if it did as it was copied in. That's a basic overrun problem, and essentially, why things crash due to overwriting memory. It would be fine to do it that way, provided the code checked that it was only filling the block to the end, not carrying on til it reached what it considered the end of a line.
That sort of thing is avoided by thinking what could go wrong, while writing the software. It doesn't really matter how complex your data is, if each step of your program doesn't allow bad data to do bad things. It shouldn't take a lot of effort to do it the right way, instead of the quick, dirty and probably disastrous way, given the right circumstances.
In this case, the whirry thing did eventually go away, as it happened, but I wouldn't have wanted to have had to wait for it. Metapad just opened it more or less straight away.
In reply to I've seen text editors crash by AndyHornBlower
Indeed, I and presumably everyone else who has contributed to the development of MuseScore understand understand how these sort of checks work and how to perform them. You are of course correct that it's not difficult in principle. It's just that MuseScore consists of hundreds of thousands (maybe even millions?) of lines of code at this point, and while these sort of checks exist in some places, they aren't *everywhere*. Going through all that code and figuring out where the additional checks are needed - and how to do it in a way that doesn't impact the performance of the program - would be a pretty monumental effort. Which isn't to say it won't ever happen, but the issue isn't that no one understands how to do it - of course we do. It's that it is an enormous effort, and so far no one has volunteered for that task.