Mixer not remembering changes in the channels

Came up again in #290206: Drumset not stored on scores imported from Finale. Please make sure that the fix for this covers that issue also. I don't think it'll take extra code.

Came up again in #290092: 3.1.0.7078 Mixer “Patch” selection can not be saved?

A few reports on this issue already, it's really inconvenient, it forced me go playback with version 2.

Going back to 3.0.5 should be sufficient, as this is a 3.1 regression

While a fix for this is developed, at least as of today the previous (some days behind) 3.1-RC builds are still available for download from https://musescore.org/en/3.1rc .

And that does not have this issue? If so this would restrict the possible culprit changes quite a lot.

At least, the 3.1-RC I just downloaded right now from the RC link above (full info: build OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.1.0.7011, revision: 8b1a7dc) ) , seem to save correctly the patch assignments in the Mixer within the score, using other soundfounts than the default.

So maybe the fix for #289562: Adding Instrument, after changing location in the Dialog, leads to crash broke this? As far as I can see this is the only change between RC and Final that deals with the mixer

I don't know, frankly I don't see the relationship by reading the code of the PR submitted at that time, in the 289562 issue you mention ( https://github.com/musescore/MuseScore/commit/f131df20b2a2c4eaa0a567c3a…).

Just rechecked again in 3.1-RC, now exiting MuseScore, deleting the non-default soundfonts in the Synthetiser (so leaving the default sf only), then loading the saved sf's +mixer assigments using "Load from Score", and it loads and plays them ok)

...I just tried with the official 3.1 (final) and well, maybe I'm wrong, but using the "Save to Score" option in the Synthetiser (ie: explicitely saving the synth settings with the score) , saving the score, closing completely MuseScore, opening the score again, and lastly using "Load from Score" , works fine??

And "load from score" is also, if it's saved to score, then this time i open it, it's loaded already, why do i click it? I never used it

@Xianyue, well, since Musescore 2.0, I've always had to use the "Save to Score" button in the Synthetiser window to save with the score the list of used soundfonts and synth settings (and the Mixer patch assigments), when using customized settings in this area. Just saving the score (File / Save or Save As) at least for me didn't saved these customized items in the score file itself (when using non default settings for the soundfont/mixer patches/other synth settings).

it's confusing to users, i always try to convince myself it means "commit" or "Apply to Score for later saving", common sense "Save" = "save everything"?

Came up again in https://musescore.org/en/node/290159.

I think this issues severity should be upgraded to S1 - Blocker due to all of the confusion it's causing and the large number of reports related to it.

You are right, considering my sf2/sfz collection is getting bigger & bigger:

It is indeed there must have a way to save customized items out of these thousands of fonts for using later. In the same App, top menu "Save Style...", "Load Style..." to a .mss file is a good example of implementing this and practically more acceptable and feasible to users, it's independently existing there ready for use forever without loading any score and retrieving from it. Having "Save Fonts Config...", "Load Fonts Config..." also is helping to achieve overall App user interface and function consistency.

Similar to style saving, users can save customized fonts selection for different types of scores, and give them meaningful names like "Violin Duet", "Dancing Guitar", "String Quarts", "WoodwindMarch", "Magic Flutes", "MuseScore 3.2 Default" ....

Xianyue賢越, you need to put your comments not related to the issue at hand in the forum. It worked fine in the past and the regression needs to be fixed.

mike320, I know it's not hard to code this, I am trying to convince MuseScore team to give up this fix NOW, and go strait forward to an open new land with fresh air.

Sorry, this was my mistake I think. Here is a fix that should fix it: https://github.com/musescore/MuseScore/pull/5094

Thanks TheOtherJThistle , looking forward to being the best App.

I'm still getting the same results after installing the nightly. How do I go back to 3.0.5

Not even the latest nightly has this yet. You'll get MuseScore 3.0.5 from https://musescore.org/en/download#Older-and-unsupported-versions

@edukehtoe, Maybe a quick solution: after opening your score, go "Load from score".

The nightly doesn't replace your installed version, so your last version is still there.

Thank you for your continued help. I can't seem to get 3.0.5.
I'm assuming that's because I have a Mac.
The latest version I can find is 2.3.2.
It is opening and playing my documents correctly. Regular Standard is working for percussion. I don't even
need to switch it.
I'm going to keep looking for 3.0.5. Perhaps I'm doing something wrong.

Someone familiar with Mac will have to help you with this. You should move further discussion of this to the forum since it's not really related to this issue.

Check https://ftp.osuosl.org/pub/musescore/releases/MuseScore-3.0.5/ and find a version for Mac there

In the meantime until a new release fixes this, is it posible to save the mixer settings directly to the mscx file? Or, what is equivalent, to write the edits directly to the mscx file.

I am unable to save mixer patch changes in the MSCX format. So far the nightlys have not made a difference. I have been able to post using 3.0.5.

The fix has not been merged and no nightly created. As long as the issue status is PR created, you won't find a nightly for it. The nightly is created after the status is changed to Fixed.

I mean if there is some documented syntax to define the patch (or whatever is planned to be included to allow saving the mixer patch settings); one that, even if not written by MuseScore itself, is recognized when loading the score from the mscx to set automatically the patches to be used. If this were the case, it would be possible to manually input the required tags.

Does <controller ctrl="32" value="0"/> help?

Fixed in branch master, commit f3d04434f1

_fix #290121: changes to non-expr patches aren't saved

fix #290147 as well_

Jojo-Shmitz,

> Does <controller ctrl="32" value="0"/> help?

Do you mean placing this Bank change each time I need the original sound?
For instance:

<Channel name="pizzicato">
<color>-65281</color>
<program value="45"/>
<controller ctrl="10" value="80"/>
<controller ctrl="32" value="0"/>
<synti>Fluid</synti>
<midiPort>1</midiPort>
<midiChannel>11</midiChannel>
</Channel>

Is this correct?
Is this what MuseScore will do when the bug be fixed?

I think so. But just try a recent development build and check yourself

It wasn´t channel 0 but 179 for Cb pizz, 169 for Vc pizz, 159 for Vla. pizz, 154 for Vn II pizz and 149 for vn I pizz.
So I had to add, for example for 149,

<controller ctrl="0" value="1"/>
<controller ctrl="32" value="21"/>

since 149 = 1*128 + 21. The magic numbers were obtained looking for the desired patch in teh mixer and looking at the contextual information when placing the mouse pointer over the name of the channel.

See #290462: Fix Symphony Orchestra template and #290429: update ensemble strings instruments to select correct presets

this one has been merged into the next release, notice says it's fixed in the status above (It'll say closed in about 2 weeks), and the other two Jojo mentioned have not yet been included though the fix has been proposed, notice the it says Status: patch (ready to commit) when you move your mouse over it.

I mentioned how I solved it becaiuse it seemed interesting to share how I managed to solve the issue manually in the meantime. I think there should be some documentation on the mscx format since frequently one has to fix things manually or try to find out what is happening. Is there any plan for doing this in the future?

since frequently one has to fix things manually
Occasionally to rarely, but certainly not frequently

How frequenty is debatable. I have found it very useful to dig into the mscx, and think it would be interesting to have it documented. However I understand there are other priorities. When I have some time I'll try to write some notes on it by doing some reverse engineering.

Request to document the mscx format had come up before and always got denied, as this can become a maintainance nightmare when the format changes.
It is meant to be a debuging format and as such really doesn't need to get documented to ordinary 'mere mortal' users.

Automatically closed -- issue fixed for 2 weeks with no activity.