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.

Comments

Jojo-Schmitz

• Jan 23, 2022 - 11:42

Use "Save As" and give the name without underscores

Bacchushlg

• Jan 23, 2022 - 12:15

In fact, what I actually do in most cases: scroll through the list and save as with the selected former name. But it would be a bit more comfortable if the original name is kept.
Is there a special reason for the underscore naming?

Jojo-Schmitz

• Jan 23, 2022 - 12:18

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"); // &auml;
      fn = fn.replace(QChar(0xf6), "oe"); // &ouml;
      fn = fn.replace(QChar(0xfc), "ue"); // &uuml;
      fn = fn.replace(QChar(0xdf), "ss"); // &szlig;
      fn = fn.replace(QChar(0xc4), "Ae"); // &Auml;
      fn = fn.replace(QChar(0xd6), "Oe"); // &Ouml;
      fn = fn.replace(QChar(0xdc), "Ue"); // &Uuml;
      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;
      }

sjha

• Jan 24, 2022 - 20:01

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.

Jojo-Schmitz

• Jan 24, 2022 - 20:20

That was in https://musescore.org/en/node/70256 and 7 years ago

sjha

• Jan 24, 2022 - 20:31

That's correct, and a long discussion it was, but it's clear from the OP on the current thread that the issue has not gone away.

Marc Sabatella

• Jan 29, 2022 - 23:11

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.

Bacchushlg

• Jan 30, 2022 - 07:59

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....)

Marc Sabatella

• Jan 30, 2022 - 18:00

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.

frfancha

• Jan 30, 2022 - 08:13

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.

Marc Sabatella

• Jan 30, 2022 - 17:56

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.

frfancha

• Jan 30, 2022 - 18:15

A legitimate decision that the name proposed by the save as dialog is different when you click save as yourself or when the save as is triggered by closing the file without saving explicitly first?

Marc Sabatella

• Jan 30, 2022 - 18:23

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.

frfancha

• Jan 30, 2022 - 19:10

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.

frfancha

• Jan 30, 2022 - 19:12

To be complete I certainly agree that for true imports (not just opening a genuine MuseScore file of previous version) then the current behaviour is indeed well designed.

Marc Sabatella

• Jan 30, 2022 - 21:15

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.

sjha

• Jan 30, 2022 - 18:31

Surely the sensible way to resolve this issue is to make the default for naming an imported file a user choice in the preferences. Then those who don't want underlines in the filenames and those who do will both be satisfied.

Marc Sabatella

• Jan 30, 2022 - 21:18

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.