Regression—playback in single part instead plays full score

see https://github.com/musescore/MuseScore/pull/2742

heuchi's PR got closed (by himself) on September 28th, because Werner is working on this.
Apparently that hasn't happened yet

Came up again: #141436: The main score playback is listened in parts instead of the parts themselves

Confirmed on MacOS, MuseScoreNightly-2018-04-09-1730-master-ddbcaf8.dmg. It is almost Critical, indeed and still not fixed.

There is more to it than this, too. It seems the part has no sound of its own, at least not after save / reload. Try this:

1) new score for one instrument
2) enter some notes
3) generate parts
4) visit the part, click some notes to verify they play
5) save
6) close
7) reload
8) visit the part again and try clicking some notes

Result: no sound at all. Hitting spacebar to commence playback works, because as noted here, it's really playing the master score. But the part has no sound at all at this point. Entering new notes is similarly silent.

Realized this working on #78591: Undo of Change Instrument does not work. As far as I can tell my code to fix that in https://github.com/musescore/MuseScore/pull/3836 is probably good, but hard to say given the fundamental issues that exist for playback in parts.

Came up again in #279142: On playback of linked parts also the other parts are heard

even almost a blocker

and again in #279140: Parts playback

It is not a regression. It was an intention. There are two options actually. We can play only selected part or we can play whole score instead. Both scenarios are important and were asked to implement several times.

So, there is a trade off. Playing solo part is still possible using Mixer. But playing whole score when part is opened was impossible before, but it is possible now.

Playing whole part is still possible, on the master score. On parts only that should play, simple as that, ebverything else is completely unexpected. It is a regression vs 2.x and an unneccesary one at that.
In a large score's parts having to scroll thru the entire list to find which instrument to solo, or mute a whole set but one, is just way to cumbersome.
A possible solution to combine "the best of both worlds" might be to automagically solo the instruments on the linked parts, that way the old 2.x behavoir is retained, but the new 3.0 one is still possible.

That seems brilliantly simple, I like it. Just as we force concert pitch off and mmrests on when generating parts but allow you to toggle these later, we could do the same for parts. There could even be a dedicated button for this in the Mixer, maybe visually combined with the Master volume, to make it easier to toggle the "Solo current part" without needing to scroll through the Mixer to find it. Or at least highlight the current part's channel column(s) (could be more than if more than one instrument is included, but, hmm, what about parts from voices...)

I do agree, btw, that the ability to easily hear the whole score while viewing a part is good; it just needs to be equally easy to hear just the part.

My comment above about sound being lost on save/reload (https://musescore.org/en/node/109941#comment-846289) remains valid. This much is critical.

@Marc better to create separate issue not to mix the discussion

OK, it's probably the same as #278918: MIDI export of a part crashes anyhow

I guess we can take #279637: Playback within parts as another vote to change the default for parts to solo that

How to get a whole score playback in this case? What we can do is to add special toggle to the mixer with the meaning of "Solo excerpt/Mute excerpt". It will cover both requests.

Update: The only question is how to make whole score sound. Maybe, the behaviour of the toggle should be "Solo excerpt/Play whole score" and let users manually mute excerpts instruments.

(linked) parts can have more than one part/instrument. So would it make more sense to solo all the instruments in the linked part or to mute the rest? Is it better for a user to have to unsoloe one (or a few), or to have to unmute all the rest, considering at least 1 ckick per instrument to solo/unsolo and mute/unmute?
I guess the most common use case is 1, maybe 2 instrument per part and the need to hear it either solo or with the full board, so solo/unsolo would be the way to go, wouldn't it?

I suggested the same, if I understand your suggestion correctly :)

Ah and at the same time. Great minds think alike ;-)

I like your proposal

Which one? :) Solo excerpt/play whole score or solo excerpt/mute excerpt?

FWIW, our first (?) vote of approval on hearing the full score when playing the part: https://musescore.org/en/comment/877473#comment-877473

Solo excerpt/play whole score
Please don't ask '"r" questions, I tend to answer those with "yes" or "no" (drives my wife nuts ;-))

Why not default the part to solo all instruments in the part, with it being set automatically in the mixer. Then add a play all button in a toolbar for the part and/or the mixer. If the button is in a toolbar, it would also update the mixer. I think a play all button in the mixer would be a nice addition any way. It could work in a manner similar to the all check box in the selection filter. That is, faded or unchecked when any mute or solo box is checked.

@Jojo, So do I lol :)

Increased the Priority because it is very frequent request (not a bug ;))

After playing a bit with the mixer, I don't see a real problem here. Soloing instruments is not a problem if a user gave them proper names. Even if a part has 4-5 instruments, it is a matter of clicking "S" button 4-5 times. It is not a problem even with orchestral score.

Implementing a smart button discussed above is a complex task which should be done, but later since we have more urgent tasks right now.

There could be different implementations of the idea. It could be a button in the mixer, but it requires auto detecting the underlying part. It could be a multiple selection in the mixer and soloing/muting multiselection with one click. It could be special Play Button behaviour or one more play button.

Good point! We need to add the info to the tour when user opens a part first time.

Something I posted in one of the linked issues already:

When batch-converting from the command line, the user can not explicitly choose to solo the part, therefore that absolutely has to be the default. (I’d be okay with “default on part creation, but user can explicitly override that later” and even that to be stored into the mscx file, though.)

Or, it could be the defaulI for converter mode only, or a new command-line option added. But FWIW, I do personally having it be the default in general.

I don’t know whether having batch export be different from what you get when you just open the file interactively is good… it clearly violates the principle of least surprise.

Not necessarily. People use batch convert for very different reasons than opening a score and viewing a part. Expectations can easily differ depending on use case. The basic issue for GUI users is, are they wanting playback to check their work, in which case part only makes sense, or are they wanting playback to play along while viewing the part, in which case score makes sense. The latter use case basically doesn't exist for batch convert.

Came up again in: https://musescore.org/fr/node/280766

One more: https://musescore.org/en/node/281119

Another one: https://musescore.org/en/node/281119

The suggestion is that you can use the mixer as a workaround.
In version 2.xx the mixer is saved per part.
However the mixer is not saved per part in version 3.xx. So what functionality does "part" have at this moment?

Unfortunately I see this regression was by design. Why remove a functionality instead of adding a functionality? A button that let's you toggle between "play all" or "play visible".

This might be a reason for me not to upgrade and to look elsewhere for future projects. That also means I will stop being a paying user.

This here is an open issue, so clearly not by design. Just not yet fixed.
And currently nothing prevents you from continuing to use MuseScore 2.x (2.3.2).
And in parallel to 3.0 (which really isn't an upgrade as it doesn't removes the previous version)
As for paying user:
The mobile apps are not yet ready for 3.0 anyhow, and the musescore.com website still accepts both formats

Sorry for misreading. In the thread it was mentioned that this was by design including a link to a request to add this functionality. Something btw I will also use if available. I'll wait patiently for the fix.
And I also have to wait for the mobile apps to start working with version 3.x Meanwhile I use version 2.x

To be clear: the new feature where you.can now to hear the whole score whole viewing a part is by design, and it's a good feature to have so it is unlikely to be removed. The fact that the default behavior has changed is also by design, but that doesn't mean the design can't be changed if it continues to appear more people prefer the old default (which was indeed the only option). And that is why this issue is still open: it is currently by design, but it is a design under review.

As.for what functionality parts, the answer is the same as they have always been intended to have: to allow you to print individual parts for the players. Playback was never really relevant to the intention behind the feature. Different peoe.use the playback of parts in different ways. For some, the new default is better, for others, the old was. No matter which is the default, it's good for some, bad for others. But as long as both behaviors are available everyone should be happy.

+1 vote for the old default.

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

And: https://musescore.org/en/node/282265

Came up again: https://musescore.org/en/node/282267#comment-888464

Came up again in https://musescore.org/nl/node/282412

Though I don't understand how something that is clearly working as designed, can be listed as a critical bug, I do see that the discussion is important, and hopefully it will end up with an improved design.

• As stated the opinions are divided, so to me the obvious solution will be to make the behaviour be decided by a new setting in Preferences.
  "Play full score from parts" or something like that.
• Regardless which choice is made it should be possible to override this by use of the Mixer. This will require that the Mixer settings are saved with each Part, so that the user can easily change between parts, and get the desired playback without the need to go back to the mixer

Implementing theese two should capture the best of both Worlds

We're working on the solution which will hopefully satisfy everyone.

The idea is to add the button in the mixer which allows switching between part-related mixer preferences (MuseScore 2 style) and the whole score ones. Part-related mixer-preferences will be enabled if user changes the tab to a part. If user wants the playback of the whole score, he/she will open the mixer and toggle the checkbox which will enable whole score mixer preferences and related playback.

If it is possible to implement without much reworking of the mixer, we will do it.

Another one: https://musescore.org/en/node/282676

Also: https://musescore.org/en/node/282677

And a third one: https://musescore.org/en/node/282693

ok this is the workaround, stay in the main sheet, with all parta, put there the loop, then switch to the part sheet, and the loop (hidden) will work there. That means that the entire sheet and the part sheet are linked always. Thanks. In version 2 this link appeared not to be, a loop in a part is not hidden and works only in that sheet. Anyhow thanks

This change shocked me - but this last comment seems to hit the mark. I was dead worried about toggling between the part instruments and all instruments, because in my full score I have loads of instruments that are muted (duplicate staves for multiple transpositions, working staves for various purposes, ...) and I certainly won't want them unmuted - for me the toggle would be between all the instruments in the part and all the instruments in the score.

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

...and #283280: Hearing parts individually from score if I make a tab

See https://github.com/musescore/MuseScore/pull/4655

Fixed in branch master, commit 738fe850ea

fix #109941: enable single part playback

Fixed in branch master, commit 27dc9000ca

_Merge pull request #4655 from dmitrio95/parts-playback

fix #109941: Single parts playback_

Fixed in branch 3.0.x, commit 2f533caae6

_Merge pull request #4655 from dmitrio95/parts-playback

fix #109941: Single parts playback_

Thanks so much Dmitri. Nice work. I'm just starting to try it. From what I see, we now have the best for everyone. The default is the expected one (well, that was my opinion!), and with a simple click in the Mixer, you can switch from one to the other behavior.
One more little effort, and I'll end up liking this V3! :)

The fix to part playing seems to be fine, but in nightly 2019-02-18-0821, a sensitive area seems to have been tickled. When I load a score from stable version 3, the playback sounds are bizarre. Looking at the mixer, all seems well, The flute part has patch Flute, the trumpet part has patch Trumpet, but they do not sound like that - usually the sound is a piano (default) but I have also other sounds. Clicking on the patch dropdown reveals that synth brass is selected for the flute, harp is selected for the trumpet ... selecting the right patch in the mixer seems to fix the problem.

I have tried other scores (from versions 2 and 3) without problems.

Should this be another issue or is it a result of the change?

By trying to do "Change Instrument" in Staff Properties for the last instrument (ie Basse Sib), let's say for another Bass, I get a crash.
Deserves more investigation. I observe right now this score was created in 2015. It would probably have been better to open a thread on the forum support, to can check first if it is reproducible or not.

Thanks. I have created #284426: Instruments play as piano with odd side effects.
The problem was introduced between nightly 2019-02-15-1723 and 2019-02-16-0933.
I could not reproduce the crash but I found something potentially worse!

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