3.1 *always* saves to the <Synthesizer> tag… appending full info on *every* save

• Jun 5, 2019 - 21:32
Reported version
3.1
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

Version: 3.1

In 2.x and 3.0, a file used to have just…

    <?xml version="1.0" encoding="UTF-8"?>
    <museScore version="3.01">
      <programVersion>3.0.5</programVersion>
      <programRevision>58dd23d</programRevision>
      <Score>
        <LayerTag id="0" tag="default"></LayerTag>
        <currentLayer>0</currentLayer>
        <Synthesizer>
          </Synthesizer>
        <Division>480</Division>
[…]

… unless the synthesiser settings were explicitly saved.

Now, in 3.1, I have a file I saved a few times, and have this:

    <?xml version="1.0" encoding="UTF-8"?>
    <museScore version="3.01">
      <programVersion>3.1.0</programVersion>
      <programRevision>e26f7c4</programRevision>
      <Score>
        <LayerTag id="0" tag="default"></LayerTag>
        <currentLayer>0</currentLayer>
        <Synthesizer>
          <master>
            <val id="0">Zita1</val>
            <val id="1">NoEffect</val>
            <val id="2">0.31989</val>
            <val id="3">440</val>
            <val id="4">1</val>
            <val id="5">1</val>
            </master>
          <Fluid>
            <val id="0">MuseScore_General.sf3</val>
            </Fluid>
          <Zerberus>
            </Zerberus>
          <Zita1>
            <val id="0">0.25</val>
            <val id="1">0.462756</val>
            <val id="2">0.161809</val>
            <val id="3">0.333333</val>
            <val id="4">0.25</val>
            <val id="5">0.335245</val>
            <val id="6">0.5</val>
            <val id="7">0.664755</val>
            <val id="8">0.5</val>
            <val id="9">0.33</val>
            </Zita1>
          <master>
            <val id="0">Zita1</val>
            <val id="1">NoEffect</val>
            <val id="2">0.31989</val>
            <val id="3">440</val>
            <val id="4">1</val>
            <val id="5">1</val>
            </master>
          <Fluid>
            <val id="0">MuseScore_General.sf3</val>
            </Fluid>
          <Zerberus>
            </Zerberus>
          <Zita1>
            <val id="0">0.25</val>
            <val id="1">0.462756</val>
            <val id="2">0.161809</val>
            <val id="3">0.333333</val>
            <val id="4">0.25</val>
            <val id="5">0.335245</val>
            <val id="6">0.5</val>
            <val id="7">0.664755</val>
            <val id="8">0.5</val>
            <val id="9">0.33</val>
            </Zita1>
          <master>
            <val id="0">Zita1</val>
            <val id="1">NoEffect</val>
            <val id="2">0.1</val>
            <val id="3">440</val>
            <val id="4">1</val>
            <val id="5">1</val>
            </master>
          <Fluid>
            <val id="0">MuseScore_General.sf3</val>
            </Fluid>
          <Zerberus>
            </Zerberus>
          <Zita1>
            <val id="0">0.25</val>
            <val id="1">0.462756</val>
            <val id="2">0.161809</val>
            <val id="3">0.333333</val>
            <val id="4">0.25</val>
            <val id="5">0.335245</val>
            <val id="6">0.5</val>
            <val id="7">0.664755</val>
            <val id="8">0.5</val>
            <val id="9">0.33</val>
            </Zita1>
          </Synthesizer>
        <Division>480</Division>
[…]

This is clearly wrong and also kinda annoying…

Perhaps this also ties into the problem of mixer changes “not saved”: maybe they are saved, but there are so many saves, the wrong settings are picked on loading.

Comments

• Jun 5, 2019 - 22:03

Mixer patches not being saved are another problem and are fixed by one of my other PRs. But this is another one of my bugs, thanks for reporting it.

I'll get a fix done for it in a day or two.

Reply

• Jun 6, 2019 - 07:27

If I were you I'd wait until 3.1.1 is released, actually. There are a few pretty critical bugs in 3.1 that have been fixed since or will be fixed, e. g. mixer patches not being saved, bad mm rest layout, bad midi export of parts, voices playing back incorrectly. I'd hope that they'll be all fixed in time for 3.1.1 which should be a more stable release to unleash upon Debian :)

Reply

• Jun 6, 2019 - 07:36

In general I'd vote strongly against releasing a 3.1 on Debian (or any other OS) that is different from what has been tagged as 3.1 on GitHub.

Reply

• Jun 6, 2019 - 17:06

Debian is the 2nd most popular desktop Linux (and the most popular server Linux), after Ubuntu, in Germany at least, both of which @mirabilos maintains MuseScore for ;-)

Reply

• Jun 6, 2019 - 21:10

@mike320 numbers (installed, not downloads) are available from https://qa.debian.org/popcon-graph.php?packages=musescore+musescore3+mu… and (in a not so nice form) https://popcon.ubuntu.com/ for those distributions themselves, excluding derivatives like KXStudio (which is very well-used).

At the time of writing, installed package numbers (among those that chose to opt-in to report, so the dark ciffre is generally much larger) look like this:

    \                     Debian   *buntu
    MuseScore 0, 1, 2.x   2045     30033
    MuseScore 3/Nightly     30         1
    Soundfonts            8683     34047
    sf3convert               1         0

Note that, currently, Debian is frozen in preparation of a new formal stable release anyway, so updates go to “experimental”.

I also suspect that the *buntu numbers don’t count the packages from the PPA (from the raw data I downloaded; the recent soundfont packages were not shown at all), so numbers there are also too low.

Reply

• Jun 27, 2019 - 16:29

I can reproduce this with 3.2 (OS: macOS Mojave (10.14), Arch.: x86_64, MuseScore version (64-bit): 3.2.0.22758, revision: 8594c8c).

Steps to reproduce:
1. Open synth-dup.mscx.
2. Click Save.
The synth settings are now duplicated.

Attachment Size
synth-dup.mscx 35.53 KB

Reply

• Jun 27, 2019 - 17:04

Even if you do not give the "Save to Score" command, it saves the current soundfont setting in the synthesizer into the file.

This is undesirable. It will cause a lot of confusion.

Example: You opened the file, just corrected some necessary things (e.g.: title) and saved the file. If you didn't give the command "load from score", the soundfont settings currently available on the synthesizer (perhaps different from the one you set for that file) have already been saved in your file.

Reply

• Jul 4, 2019 - 23:51

3.2.2 does not, for me, for scores that currently have an empty Synthesiser tag.

(The bug from Ziya’s anigif is for scores with a nonempty one.)

Reply

• Jul 5, 2019 - 21:42

If the synthesizer settings have never been saved on the score, the software may not be able to add these settings to the file because it cannot find the required tags.

But every score I create has different soundfonts and settings.

I save the settings to every file I create.

That is, those who do not save the synthesizer settings to the score may not be affected to this bug (Maybe those who always use the default soundfont, so they don't need to save the synthesizer settings).

Reply

• Jul 5, 2019 - 21:48

To be 100% clear, you’re talking about a new bug here. The initial bug was precisely “synthesiser state is saved even if the user did not save them to the score, and appended on each save”, which is now fixed.

But it’s kind of a follow-up bug, so I’m fine with keeping the discussion collected here.

Reply

• Jul 6, 2019 - 14:24

As far as I can remember: The reason for this bug is that it occurs after a fix related to the failure of new files to match the synthesizer configuration. Somewhere between 3.0 and 3.1.

My guess: A fix was made to read the existing synthesizer settings before opening the file. The problem may have come up in the meantime.

PS: I follow the fixes (approved PR's), but I can't remember the numbers and locations of all of them.

Reply

Fix version
3.3.0