auto generated score name with underscores

• Jan 23, 2022 - 11:27

I have a couple of scores that were written with MS V2. After opening and then close, I am asked to save them (because they were internally updated to V3 format, which is ok for me).
But unfortunately in most cases, the score gets a new name with replacement of blanks to underscores.
I would prefer to overwrite the opened score directly, with it's original name.


In reply to by Bacchushlg

It is not just spaces, but also umlauts (äüö) and some other special characters that are getting replaced/transscribed. Those are problematinc on some platforms. Here's the source code:

static QString createDefaultFileName(QString fn)
      // special characters in filenames are a constant source
      // of trouble, this replaces some of them common in german:
      fn = fn.simplified();
      fn = fn.replace(QChar(' '),  "_");
      fn = fn.replace(QChar('\n'), "_");
      fn = fn.replace(QChar(0xe4), "ae"); // ä
      fn = fn.replace(QChar(0xf6), "oe"); // ö
      fn = fn.replace(QChar(0xfc), "ue"); // ü
      fn = fn.replace(QChar(0xdf), "ss"); // ß
      fn = fn.replace(QChar(0xc4), "Ae"); // Ä
      fn = fn.replace(QChar(0xd6), "Oe"); // Ö
      fn = fn.replace(QChar(0xdc), "Ue"); // Ü
      fn = fn.replace(QChar(0x266d),"b"); // musical flat sign, happen in instrument names, so can happen in part (file) names
      fn = fn.replace(QChar(0x266f),"#"); // musical sharp sign, can happen in titles, so can happen in score (file) names
      fn = fn.replace( QRegExp( "[" + QRegExp::escape( "\\/:*?\"<>|" ) + "]" ), "_" ); //FAT/NTFS special chars
      return fn;

I raised this issue some time ago in the forums. The answer given was that using file names containing spaces was considered problematic. I never accepted this argument. Think of all the programmes that permit spaces in their filenames - word processors, graphics,, databases... in fact I can't think of any programme other than Musescore that takes this view. At the very least Musescore should have saving files without inserting underscores as an option in the preferences.

In reply to by sjha

It is problematic - even if all computers* accept spaces in their filesystem, that isn't for the web, nor is it true for all programs that use files (eg, terminal programs).

But anyhow, MuseScore mostly certainly does permit spaces in filenames. So you are free to use spaces yourself if you are OK with the consequences. It's just that MuseScore won't offer a default name that is known for a fact to be problematic.

In reply to by Marc Sabatella

Please have a look at my original demand: I have a file that has been created under MS V2. After opening in V3 it is converted implicitly, what is ok for me. I am asked to save this new version when closing it, and I would prefer a simple "yes" and save it under the same name as the original file (I don't use V2 any more - which I assume is the same for most users....)

In reply to by Bacchushlg

Any time a file is imported - whether from MuseScore 2, or MIDI, or MusicXML, or any other supported format - MuseScore needs to generate a filename for the saved file. As mentioned, MuseScore will not generate a filename that is known to be problematic.

If you're OK with overwriting the original file, the simple way to do that is simply click it in the file listing within the dialog.

Your problem is a well known one, if you let MuseScore 3 go up to the test where it says "oh attention that file has been saved with version 2, you must save, blablabla..."
Once in this stage, MuseScore reapplies the algorithm to compute the default file name instead of reusing the one you have carefully chosen for version 2.
Obvsiously a bug (for which there has been reports) but clearly will never be fixed (at least never in version 3).
However there is a simple trick / workaround: use explicitly the option "Save as..." before letting MuseScore prompts you.
If you do that, the menu save as will be opened with the existing name as starting point instead of reapplying the algorithm.

In reply to by frfancha

It's not a bug; it's working exactly as intended. MuseScore-generated filenames are, by design, ones that will work on any platform. If you wish to use a filename that will break in some use cases, that's your right, but the generated ones won't do that.

Now, design decisions are not set in stone. it's certainly possible this design could be reconsidered. First step in that is to stop calling ait a bug, and acknowledge it's a legitimate design decision made for legitimate reasons. Next step is to display an understanding of what the technical issues are. Next step after that is to propose an alternative solution that solves your unique use case while not breaking things for others.

In reply to by frfancha

As mentioned many times in the various discussions here, import always involves generating a new filename, as often you don't want to overwrite the original file. If you do want to overwrite the original file, just click the original in the listing.

"Save As" always uses the current name as the default, import or not. Very possibly it should notice that the file was imported and not do this. if you'd like to report a bug against the "Save As" command, so it correctly recognizes the import and generates a new filename, that can certainly be considered for fixing. I'm guessing you'd rather keep this bug intact, and I certainly won't be going out of my way to fix it.

In reply to by Marc Sabatella

Only reason why opening a V2 file in V3 is considered an import is because file format is not downgrade compatible. From the user point of view it is not an import and the name that has been (potentially) carefully selected has no reason to be lost.
Never would MS-Word suggest again to use the document title as file name when going from version to version and make you lose your original file name, it doesn't make any sense.

In reply to by frfancha

The fact that the format is not compatible is precisely why it's considered an import indeed, and thus it's precisely why the same reasoning applies. A file saved in MuseScore 3 won't be openable in the program that created the file (whether that program is MuseScore 2 or something else), it's important not to simply save over it, but to offer a chance to choose a new filename. And for the sake of consistency (elsewhere I believe you suggested you value that), also for the sake of maintainability in the code, it makes sense to use the same algorithm either way.

As I mentioned, it's possible a different design could be considered in the future.

In reply to by sjha

That's certainly a possibility. So far, no one who understands the issues well enough to implement this has found it a valuable enough thing to volunteer their time to actually do the coding. But perhaps someday someone will be sufficiently motivated. Such is the nature of open source software. Features that are important to larger number of users are more likely to be implemented. But even if only one person values a feature, if they volunteer to implement it themselves and show that their code doesn't break anything for anyone else or introduce any maintainability or support or other issues, then it has a chance of making it into a future version.

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