New HQ soundfont not fully compatible with 3.0.5

• Apr 24, 2019 - 18:15
Reported version
3.x-dev
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
MuseScore

1) Starting point: 3.0.5 installed and a score with several bowed string, woodwind and classic guitar loaded (Preferences include "continue last session").
2) Install 3.1 beta on a different folder.
3) Open 3.1. Last session from 3.0.5 opens automatically.
3) Install from the resource manager the HQ soundfont MuseScore_General_HQ.sf3.
4) Play the score: it works fine and recognizes single-note dynamics.
5) Close 3.1 beta and open 3.0.5.
6) Play the score. Only pizzicatos and classic guitar are played. Bowed strings and woodwind are silent.
7) Looking at Synthesizer, it appears that the HQ soundfont has been installed and it is abpve the original soundfont.

Workaround: Go to Synthesizer and move to top the old soundfont MuseScore_General.sf3. the process is quite slow (seems that the application has frozen, but after a couple of minutes the change takes place). Now the score plays as usually (no single-note dynamics, of course).

Comments

• Apr 24, 2019 - 19:40
Workaround No ⇒ Yes

Confirmed, that is because 3.0.5 doesn't the Expression sounds, but 3.1 changes to them. Not a matter of the soundfont itself, but a backwards compatibility issue with 3.1 and 3.0.x.

Reply

• Apr 24, 2019 - 22:47

I made no change nor saved the file during the test in 3.1 beta, the only change has been that the HQ soundfont was placed on top of the list by 3.1 beta, so I still think that it is the HQ soundfont that presents some sort of incompatibility.
Suppose I manage to independently download the HQ soundfont, such as if I download and install it in a machine with 3.1 beta, then go to other machine with 3.0.5 only and copy the 81 Mb soundfont to the relevant location and select it from the synthsizer dialog... isn't it equivalent to what has happened?
Anyway, I think that, as a general rule, the installation of a beta version should leave any previous installation untouched, instead of trying to use the same location for important files. As it is an experimental and probably unstable version, testers may try setting changes that they don't want in the official release they are currently using for their projects.
I must confess I was shocked when almost all sound disappeared... until I calmed down and figured out where could be the problem...

Reply

• Apr 25, 2019 - 04:52

Then I'd like to see a score showing that.
I had that effect only with a score saved in 3.1.
Also look into the mixer, which sounds does it show?

Reply

• Apr 25, 2019 - 08:23

Here is an example created using 3.0.5. With the original soundfont it works fine, with the HQ soundfont several instruments don't play. However, instead of creating the score from scratch I selected a silent measure from the score I was working on and saved it with a different name. Checking the Mixer as you suggest I discover that the instruments not playing are those whose patches have the appended label "Expr.", the same as in my "original" score (I mean, the oiginal one after opening it in 3.1 beta).

I'm not quite sure now, but maybe I really saved it in 3.1 beta, even if I'm quite certain that I made no change. May be it was autosaved? (I don't know if the autosave feature really overwrites the file or writes a recovery file). How come 3.1 beta changed the original instruments to "Expr." ones, I don't know. I didn't ask to. Probably when detecting a crescendo, if the HQ is on top of the list, it changes normal patches to "Expr." ones, even if the HQ soundfont includes normal patches as well.

Now I think we are both correct. It is true that there is a backward compatibility issue when saving, since if for whatever reason the score included "Expr." patches, they will not play in 3.0.5. But it is also true that the HQ soundfont is not fully compatible with 3.0.5 since not all patches will play.

However, I also think it is not correct that 3.1 beta (or the future stable release) changes the instrument without warning, since it is not only a question of playing or not a crescendo (which by the way is a great feature), but the sounds are completely different, even the loudness balance (or may be the velocity map) between instruments differs in both soundfonts, which may cause that the work done to attain a certain balance between parts (sometimes a fine tuning of dynamics) be thrown away.

Attachment Size
Test_HQ.mscz 15.37 KB

Reply

• Apr 25, 2019 - 08:26

Hmm, that score has last been saved with 3.0.5. Can't tell whether it before might have been saved with 3.1, although I'm quite sure that it did as otherwise I beliebe it wouln't have this:

        <Channel>
          <controller ctrl="32" value="17"/>
          <program value="73"/>
          <controller ctrl="10" value="52"/>
          <synti>Fluid</synti>
          <midiPort>0</midiPort>
          <midiChannel>0</midiChannel>
          </Channel>
 

Workaround: in 3.1 go to synthesizer and change to non-expressive, then save score, check attached.
And no, Autosave won't cause this, it saves to a different location and with a different name.

Attachment Size
Test_HQ.mscz 15.26 KB

Reply

• Apr 25, 2019 - 08:51
Severity S4 - Minor ⇒ S3 - Major
Priority ⇒ P1 - High

Unless this is just a temporary problem due to having installed 3.0.x and 3.1 Beta + the HQ soundfont in parallel and the fact that both versions share settings...

Reply

• Apr 25, 2019 - 22:19

This score in particular has not been saved in 3.1 beta, but, as I said, it comes from expanding a "template" measure extracted from one that may have been inadvertently saved in 3.1 beta.
I examined a previous "non contaminated" backup of the original score and indeed it lacks the

controller ctrl="32" value="17"/

bank select control change.

Reply